Yeah, I've actually played around with a "FastRectangleClipper" concept in JTS, for just this kind of problem.
Although it started turning out to be almost as complex as the original intersection code, so I back-burnered it since it wasn't clear it was going to be a big win. Although perhaps there's an opportunity to do something simpler, which does a "rough clip" to a bounding box - ie clips off segments which lie fully outside a BB, but doesn't worry too much about single segments which go outside the box. In other words, let the drawing engine do the final clipping (which it's really good at), but don't pass it too many segments to start with. This wouldn't be too hard to implement, actually - just scan along the linestring, splitting it where segments lie outside the BB, and tossing away those segments. I don't have a lot of time right now to take a crack at this, but if someone else wants to do it I"m happy to incorporate this in JTS. Larry Becker wrote: > Getting back to Stefan's 1000 point linestring problem, the issue here is > clipping extents. As he determined, it is much faster when a large > linstring is broken into 2 point linestrings. This is probably because > instead of an expensive clipping operation to find the intersection of the > 1000 point linestring with the viewport, most of the 2 point linestrings are > being trivially rejected as being outside. This suggests that we could > implement your solution behind-the-scenes to optimize drawing, however I > believe that the multiple 2 point linestrings would appear visually > different at the shared endpoints due to being drawn twice, so this is > probably not a good idea. Any other kind of optimization would probably be > best performed in JTS. Perhaps we could interest Martin in the test case. > :-) > > regards, > Larry > > > On Fri, Feb 19, 2010 at 11:40 AM, Stefan Steiniger <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 >>> >>> >>> >>> On Fri, Feb 19, 2010 at 5:42 PM, Larry Becker <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 >>> 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 >> >> > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------------ 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
