yep :)
Larry, if we would have a trophy for the programmer of the season, you
would clearly qualify...
Martin Davis wrote:
> You'd make a good grizzly bear, Larry 8^)
>
> Larry Becker wrote:
>> I manufactured a dataset from scratch to try out the problem.
>>
>> Larry
>>
>> On Wed, Feb 24, 201
You'd make a good grizzly bear, Larry 8^)
Larry Becker wrote:
> I manufactured a dataset from scratch to try out the problem.
>
> Larry
>
> On Wed, Feb 24, 2010 at 5:01 PM, Larry Becker wrote:
>
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
---
Great!
I dunno why we (ahem - Jon) didn't notice this way back when we first
wrote this code. Always easier not to check for special cases, I
guess... 8^)
I'm betting this should be faster across the board for linear features.
The intersection() method is very slow (for use in situations li
>
> So one thoughts is that maybe there's no point in clipping linear
> features? I think Swing is pretty good at rendering lines and clipping
> them by itself.
>
Nice work Martin! I just couldn't bear (8^) the the thought of slow
linestring rendering, so I added (and committed) a check for line
Ok, I've looked at Stefan's killer bear lines. 8^) (Those grizz sure
get around...)
I see the very slow performance in OJ. I also tried this in the JTS
Test Builder app, which *doesn't* do an intersection() to clip the
geometries to the viewport. The rendering is lightning fast using this
sure
Martin Davis schrieb:
> Stefan, I'm curious - can you send them to me too?
>
>
>
> Stefan Steiniger wrote:
>> Hei Larry,
>>
>> I will send them offline.
>>
>> stefan
>>
>> Larry Becker schrieb:
>>
>>> I'm waiting on Stefan's magic 1000 point polygon. Mine draws too
>>> quickly to ben
Stefan, I'm curious - can you send them to me too?
Stefan Steiniger wrote:
> Hei Larry,
>
> I will send them offline.
>
> stefan
>
> Larry Becker schrieb:
>
>> I'm waiting on Stefan's magic 1000 point polygon. Mine draws too
>> quickly to benchmark.
>>
>> On Tue, Feb 23, 2010 at 10:08 AM, S
Hi Stefan,
Thanks. Wow! Pretty slow rendering indeed.
Larry
On Wed, Feb 24, 2010 at 10:35 AM, Stefan Steiniger wrote:
> Hei Larry,
>
> I will send them offline.
>
> stefan
>
> Larry Becker schrieb:
> > I'm waiting on Stefan's magic 1000 point polygon. Mine draws too
> > quickly to benchmar
Hei Larry,
I will send them offline.
stefan
Larry Becker schrieb:
> I'm waiting on Stefan's magic 1000 point polygon. Mine draws too
> quickly to benchmark.
>
> On Tue, Feb 23, 2010 at 10:08 AM, Sunburned Surveyor
> mailto:sunburned.surve...@gmail.com>> wrote:
>
> Larry,
>
> Kudos
I'm waiting on Stefan's magic 1000 point polygon. Mine draws too quickly to
benchmark.
On Tue, Feb 23, 2010 at 10:08 AM, Sunburned Surveyor <
sunburned.surve...@gmail.com> wrote:
> Larry,
>
> Kudos for your work on improving rendering performance in OpenJUMP.
> Should we test the fix you mention
Larry,
Kudos for your work on improving rendering performance in OpenJUMP.
Should we test the fix you mention where we "rough clip" large
lineStrings that contain the viewport in their bounding box?
The Sunburned Surveyor
On Mon, Feb 22, 2010 at 3:04 PM, Larry Becker wrote:
> If the problem is
If the problem is what we have been assuming, I see where Martin's algorithm
could be applied:
com.vividsolutions.jump.workbench.ui.renderer.style.StyleUtil#toShape()
We could do a conversion of large linestrings whose bounding boxes contain
the viewport, to "rough clip" MultiLineStrings instead
Yeah, it seems to me that I haven't seen much speed impact from
rendering fairly large linestrings. I suppose it's possible that if the
linestring was really complex the intersection() computation might be
slow, however.
In any case, computing a full intersection() is definitely doing more
wo
Better send it to me too. All the cases I've found in the wild render very
quickly. See the attached for an example.
Larry
On Mon, Feb 22, 2010 at 4:13 PM, Martin Davis wrote:
> Stefan, for future reference can you send the linestring, and the
> viewport which causes the problem?
>
> Stefan S
Stefan, for future reference can you send the linestring, and the
viewport which causes the problem?
Stefan Steiniger 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 mo
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 t
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
Hi,
Thanks Larry, fixed.
I had a quick look to check if I could do it myself, but for a few
weeks, I've just enough time to test your many improvments ;-)
Michaël
Larry Becker a écrit :
> Good catch! I had some obvious cut and paste errors. I should be
> fixed now.
>
> Larry
>
> 2010/2/19 Mi
Good catch! I had some obvious cut and paste errors. I should be fixed
now.
Larry
2010/2/19 Michaël Michaud
> Larry Becker a écrit :
> > @Michaël, Selection Renderer's Paint now returns immediately with
> > passed geometry's envelope doesn't intersect viewport. This should
> > speed up your
Larry Becker a écrit :
> @Michaël, Selection Renderer's Paint now returns immediately with
> passed geometry's envelope doesn't intersect viewport. This should
> speed up your test case for high zooms significantly.
Excellent ! It is much faster now in my test case.
Could this one be a side effe
@Michaël, Selection Renderer's Paint now returns immediately with passed
geometry's envelope doesn't intersect viewport. This should speed up your
test case for high zooms significantly.
@Sunburned, your proposal for skipping very small text labels sounds
reasonable. In practice, unless text is
Good job Larry! You identified our problem and another of other
possible rendering improvements along the way!
Maybe it would be worth skipping text labels that we know aren't
visible at the current scale, even if min rendering scale isn't set by
the user.
The Sunburned Surveyor
On Fri, Feb 19,
OK, wow. It just takes that long to render a lot of text that is too small
to see. So there is no real problem here, at least one that can't be solved
with the Scale tab of Change Styles.
Hmm, I'll wait for luca's reply.
On Fri, Feb 19, 2010 at 3:35 PM, Larry Becker wrote:
> I'm homing in on
I'm homing in on the problem. I've determined it only occurs when a layer
has labeling turned on.
@luca, can you confirm this?
Larry
On Fri, Feb 19, 2010 at 3:26 PM, Larry Becker wrote:
> HI Michaël,
>
> Your hypothesis about selection painting is correct. The call to
> StyleUtil.paint in Abs
HI Michaël,
Your hypothesis about selection painting is correct. The call to
StyleUtil.paint in AbstractSelectionRender is unconditional. Only the
handle painting is optimized for the viewport. I'm not sure how important
it is to optimize this, but let's put it off until after the redundant
ren
Let's not get distracted trying to optimize redraw. The problem I'm seeing
occurs AFTER redraw is complete.
I've done several more tests and have determined that the RenderManager
Timer event is not stopping after the panel is visually redrawn. This
occurs no matter how large the dataset is, but
OJ is optimized to only draw items that intersect the viewport.
Unfortunately, it takes work to determine which are which.
Larry
On Fri, Feb 19, 2010 at 3:09 PM, Sunburned Surveyor <
sunburned.surve...@gmail.com> wrote:
> Michael wrote: "It seems that selection rendering do not limit the
> rende
Michael wrote: "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)"
Does this mean we could speed things up by only painting the selected
features
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 m
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
tes
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
luca marletta
www.beopen.it
On Fri, Feb 19, 2010 at 5:42 PM, Larry Becker 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 appear
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
On Fri, Feb 19, 2010
luca marletta
www.beopen.it
> @Luca, would you please try to duplicate the problem using the 1.3 release?
Hi Larry, thanks fro quick buf fixing.
So..
I replicated trouble with same data on 1.3.
The problem is still there.
In my opinion the mouse wheel feature is a sort of amplification
becaus
Thanks for the inspection Larry, and for posting the code.
The Sunburned Surveyor
On Fri, Feb 19, 2010 at 7:30 AM, Larry Becker wrote:
> Well, there is good news and bad news. The good news is that the selection
> feedback slowdown issue that I am duplicating was not caused by the mouse
> whee
Well, there is good news and bad news. The good news is that the selection
feedback slowdown issue that I am duplicating was not caused by the mouse
wheel zoom mod. The bad news is that the issue is also present in the OJ
1.3 release. It is not, as I thought, related to differences in
RenderMana
Hi,
I have duplicated a problem in OJ with selection feedback. When a large
vector dataset is loaded, and mouse wheel zoom is used to zoom out,
selection feedback stops working for a while. Note that the selection
mechanism is still working as verified by the status panel, but items do not
hig
.@gmail.com]
> Lähetetty: 19. helmikuuta 2010 10:26
> Vastaanottaja: OpenJump develop and use
> Aihe: [JPP-Devel] delay on rendering
>
> Hi,
> I'd like to check opinions about the new feature to speed up zoom is
> very powerful but in my case causes a delay on on every other events
Hi,
I'd like to check opinions about the new feature to speed up zoom is
very powerful but in my case causes a delay on on every other events
and it becomes really not much nice to work.
I observe delay for window menu on right mouse click, select items and so on.
Could you write comment to under
39 matches
Mail list logo
