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 5/29/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > Larry Becker a écrit : > > >SS, > > > > I didn't find it necessary to do special (i.e. wireframe) rendering > >when doing mouse wheel zooming since worse case render times are now > >so short in SkyJUMP, and anyway the renderer doesn't block the UI, > >whereas the zoombar renderer is modal and blocking. Mouse wheel > >zooming works even in the quasimodes (anytime the zoom tool is > >showing). > > > > > Hi, I definitely should have had a look to your mousewheel zoom before > improving the zoombar. > That time, I was decided to fix the bug first, next time, may be I'll do > the other way :-) > > > The Zoom Realtime tool in SkyJUMP uses raster stretching to give a > >much smoother zoom preview than the "flashy" wireframe zoom. > > > > > So many ways to zoom ! Finally, what is the prefered way to zoom in and > out from your user point of view : simple zoom, zoombar, mousewheel zoom > or realtime zoom ? > > Michaël > > >regards, > >Larry Becker > > > > > >On 5/29/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > > >>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 render features as gray > >>wireframes (I made the decimator's resolution a Java2DConverter property > >>to use a special 2 pixel wide resolution for the wireframe display) > >>3 - Instead of displaying 100 random geometries as wireframe, I display > >>200 geometries choosen for their bigger size and so I get a better > >>feedback (the way geometries were choosen, with a 10000 points dataset > >>and another 100 polygons dataset, I get only one or two polygons on the > >>screen during mouse dragging)." > >> > >>This sounds like awesome work Michael! > >> > >>Michael wrote: "May be it would have been cleaner to create a special > >>renderer for the gray wireframe renderering..." > >> > >>This is an interesting idea. I had set up my pluggable renderer to > >>select a custom renderer based on the type of object being rendered, > >>not on the "mode" that OpenJUMP was in. I'm not sure how I would > >>select a custom renderer based on the "mode" of OpenJUMP, but I'll > >>think some more about it. (By "mode" I mean something like "OpenJUMP > >>is in mouse wheel or scale bar zoom mode.") > >> > >>Michael wrote: "Hope those optimizations will be useful for a mousewheel > >>zoom > >>implementation." > >> > >>I think you are correct about this. I was hoping to enable mouse wheel > >>zoom with my work on the cursor tool framework, so this will be of > >>interest to me. I think Larry Becker has already done some work like > >>this. I wonder if he implemented the types of optimizations we are > >>discussing. > >> > >>The Sunburned Surveyor > >>On 5/27/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > >> > >> > >>>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 features as gray > >>>wireframes (I made the decimator's resolution a Java2DConverter property > >>>to use a special 2 pixel wide resolution for the wireframe display) > >>>3 - Instead of displaying 100 random geometries as wireframe, I display > >>>200 geometries choosen for their bigger size and so I get a better > >>>feedback (the way geometries were choosen, with a 10000 points dataset > >>>and another 100 polygons dataset, I get only one or two polygons on the > >>>screen during mouse dragging). > >>> > >>>May be it would have been cleaner to create a special renderer for the > >>>gray wireframe renderering... > >>> > >>>Hope those optimizations will be useful for a mousewheel zoom > >>>implementation. > >>> > >>>Michaël > >>> > >>>Larry Becker a écrit : > >>> > >>> > >>> > >>>>Hi Michaël, > >>>> > >>>>Here is Stefan's post about the problem. The polygons must be very > >>>>large to prevent the simplification logic of zoombar from working. > >>>> > >>>>Stefan: > >>>> > >>>> > >>>>>I loaded a large shp file with 16 very large polygons (> 5000 points) > >>>>>and zoom to full extent. > >>>>>When i moved the slider of the zoom bar (zooming out) the systems does > >>>>>nothing (is blocked) for more than 30 seconds (or even more). > >>>>>If make the same thing with an older version of jump it takes one 2 sec > >>>>>after seeing the outlines and one sec more for filling. > >>>>> > >>>>> > >>>>Hei Larry, > >>>> > >>>>Larry Becker schrieb: > >>>> > >>>> > >>>>>Hi Stefan, > >>>>> > >>>>> 1. Is there somewhere I can get a copy of the shape file to test with? > >>>>> > >>>>> > >>>>i upload it here: > >>>> ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip > >>>><ftp://ftp.geo.unizh.ch/pub/sstein/openjump/brdlaender.zip> > >>>> > >>>> > >>>> > >>>>> 2. Is the speed up working for other large shape files? > >>>>> > >>>>> > >>>>i have not tested > >>>> > >>>> > >>>>> 3. Does it perform better if you zoom to full extents instead of using > >>>>>the Zoom bar. > >>>>> > >>>>> > >>>>yes - (or as usual) > >>>> > >>>> > >>>>> 4. What is the Committed Memory showing after you load the file? > >>>>> > >>>>> > >>>>mhm.. not that much: 11MB > >>>> > >>>> > >>>>> 5. After the blocked behavior, does the Committed Memory go down? > >>>>> > >>>>> > >>>>14 MB > >>>> > >>>>btw: panning is fine, and if i use Zoom to scale it is fine as well. > >>>> > >>>>thanx for taking care > >>>>stefan :) > >>>> > >>>> > >>>>regards, > >>>>Larry > >>>> > >>>> > >>>> > >>>------------------------------------------------------------------------- > >>>This SF.net email is sponsored by DB2 Express > >>>Download DB2 Express C - the FREE version of DB2 express and take > >>>control of your XML. No limits. Just data. Click to get it now. > >>>http://sourceforge.net/powerbar/db2/ > >>>_______________________________________________ > >>>Jump-pilot-devel mailing list > >>>Jump-pilot-devel@lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >>> > >>> > >>> > >>------------------------------------------------------------------------- > >>This SF.net email is sponsored by DB2 Express > >>Download DB2 Express C - the FREE version of DB2 express and take > >>control of your XML. No limits. Just data. Click to get it now. > >>http://sourceforge.net/powerbar/db2/ > >>_______________________________________________ > >>Jump-pilot-devel mailing list > >>Jump-pilot-devel@lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > >> > >> > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- http://amusingprogrammer.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
