Hi,
I can't help much as I did not notice any problem with selection and
zoom features.
I have a little regret about the delay after zooming as the zoom is very
fast but I have to wait a little 0.7s to see the new vector drawing.
About selection and zoom / unzoom with a huge dataset, here are my figures
intel core i7 / 64 bits windows vista but used with a 32 bit version of java
dataset : 177 545 features, 31 901 665 points
selection : 43217 features, 4 850 086 points (max = 57 398 points for
one feature)
redraw for
very low zoom : 14 s + 6 s for selection
low zoom : 8 s + 27 s for selection
medium zoom : 8 s + 35 s for selection
high zoom : 8 s + 48 s for selection
very high zoom : 15 s + 51 s for selection
(very unprecise measure, but enough to make hypothesis)
It seems that renderer optimization is very efficient for both
unselected features and selected features
(optimizer draws only points separated by one pixel or so) as we can see
that very low zoom is very fast
It seems that selection rendering do not limit the rendering to the
viewport (for high zoom
rendering is slow, and periods where features are drawn on screen
alternate with periods where nothing happen)
Just hypothesis. Hope that helps.
Michaël
Larry Becker a écrit :
> Interesting results. However, on a hunch, I did a test with even
> more interesting results. On Windows, open Task Manager and watch the
> CPU Usage while OJ renders a large dataset. After the rendering is
> visually complete, OJ continues to use CPU cycles for much longer -
> almost a minute in my test. After the CPU Usage finally drops,
> selection feedback starts working.
>
> This is might be an indication that multiple redundant layer redraws
> are occurring. Since selection feedback is drawn last, it must wait
> for all of this to finish. I don't have any ideas as to what might be
> causing this, does anyone else?
>
> regards,
> Larry
>
> On Fri, Feb 19, 2010 at 11:40 AM, Stefan Steiniger <sst...@geo.uzh.ch
> <mailto:sst...@geo.uzh.ch>> wrote:
>
> mhm.. ok, so I would guess the problem is related to the size of the
> geometries and its drawing?
> I recently had a problem - drawing a linestring that consisted of more
> than 1000 points. I couldn't do anything for 20-30 seconds on MS
> Vista,
> my XP was a bit faster. However, the problem solved when I
> connected the
> 1000 points with linestrings that have only a start and endpoint, i.e.
> instead of drawing 1 linestring a had to draw now 500, but here
> the 500
> lines could be drawn one after each other, and everything is done
> within
> 2-3 seconds (instead of 20 secs)
>
> (if Larry wants to test, I can send that linestring?)
>
> however, I am not sure why working with the 1000 points linestring
> is so
> slow (i.e. does paint make some tests?)
>
> stefan
>
> luca marletta wrote:
> > luca marletta
> > www.beopen.it <http://www.beopen.it>
> >
> >
> >
> > On Fri, Feb 19, 2010 at 5:42 PM, Larry Becker
> <becker.la...@gmail.com <mailto:becker.la...@gmail.com>> wrote:
> >> Hi luca,
> >>
> >> When you try to select features, does the status bar quickly
> show your
> >> selection count, even though no selection handles appear?
> >>
> >> If not, this explains why the right click menu is not
> appearing. It needs
> >> selection information to enable or disable options.
> >
> > Larry, no I had not much problem with showing selection count,
> is anyway quick.
> >
> > I noticed an important stuff.
> >
> > May dataset is full of large and aggregated geometry and in this
> case
> > I guess geometry index can not much help.
> >
> > If I explode all, I reduce the delay a lot.
> >
> > luca
> >
> >
>
> ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
>
> --
> Larry Becker
> Integrated Systems Analysts, Inc.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
