Michael wrote: I did not do much comparisons between jump versions
but identified
several bottlenecks in zoombar code and just committed an optimized
version :
1 - I prevent the renderer to display invisible layers as wireframes
during mouse dragging
2 - I used Larry's coordinate's decimator to
Hi Michaël,
It does seem like we are overly rich in zoom tools. With the
addition of mouse wheel zooming, the basic zoom tool is still the most
flexible. As a user, I like RealTime zoom sometimes because the
others are too coarse and I need to fine tune the zoom quickly.
regards,
Larry
On
Hi,
I did not do much comparisons between jump versions but identified
several bottlenecks in zoombar code and just committed an optimized
version :
1 - I prevent the renderer to display invisible layers as wireframes
during mouse dragging
2 - I used Larry's coordinate's decimator to render
Michaël, it looks like you need to mediate this dispute between me and
Stefan. Stefan claims that the decimation optimization caused the zoombar
to get very slow when given some worst case very large polygon data that he
has. I claim that the problem occurs even without the optimization, and
Stefan Steiniger a écrit :
actually a question:
Larry, Michael: Did somebody change the zoombar behaviour - so that it
starts zoom on release and not in between, when the bar is still moved?
This would be necessary if we take over the rendering improvements from
skyjump - otherwise it may
Ha,
I didn't remember there may be a link between optimization code and
zoombar...
I'm just doing test for decimation code and I will add these tests if
necessary.. I don't think there is a relation between renderer
optmization and zoombar anyway.
Michael
Larry Becker a écrit :
Michaël, it
