Home » Eclipse Projects » GEF » polyline not clipping?
polyline not clipping? [message #201111] |
Sat, 29 October 2005 04:42  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i'm seeing what seems like relatively slow performance on polyline
drawing. on a cursory browse through the relevant draw2d code (which i
traced back to swt.GC.drawPolyline) it appears that polylines are not
getting clipped to the clip area before being painted. is this correct?
if so, it might explain the slow performance i'm seeing. the clipped
area is a small part of the entire canvas, and the polyline could be
painting many unnecessary points.
is there a "standard" fix? (it doesn't seem like there would be, but you
never know until you ask). or is one supposed to do the clipping in user
code before painting the polyline?
|
|
| | |
Re: polyline not clipping? [message #201179 is a reply to message #201171] |
Sun, 30 October 2005 21:46   |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
AFAICT, the clip area is being set correctly.
somewhere in the the polyline paint code there is a slow iteration over
all points in the polyline, even those outside the clip area. i don't
even know for sure that there's an actual paint operation on each point
that's slowing things down, although that seems likely.
my post wasn't meant to suggest that there's anything "wrong" with the
default behavior. i'm not sure who should clip a polyline.
in this case, the application is actually a good place, because it knows
enough about the model structure and layout to optimize the clipping
algorithm. if this is typical, then SWT/draw2d/GEF is _not_ a good place
to do the clipping, and its better left to user code. in fact,
attempting a clip using a linear-time algorithm (unavoidable in the
general case) may prove to be just as detrimental to performance as the
current behavior.
the point was worth mentioning because it's the first time i've seen a
serious performance issue using GEF/draw2d. it happened on a large (but
realistic) test model. i'm actually quite pleased that it proved so easy
to fix the problem within the framework.
on balance, i guess i don't think draw2d/GEF should change anything
about this behavior. even so, the clipping issue may be worth mentioning
somewhere in the polyline docs.
Randy Hudson wrote:
> Are you saying that the GC is not having its clip set, or are you saying the
> points that are being painted should be clipped, so instead of drawing the
> entire polyline we would draw individual segments? Shouldn't the OS do this?
>
|
|
| | | |
Re: polyline not clipping? [message #201766 is a reply to message #201570] |
Thu, 03 November 2005 04:00   |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
this application is very different from the standard UML-Diagram'ish
flavored GEF app. it's a graphing app (like JFreeChart). in this
particular case, the polyline represents a function, most of which
(9/10ths or more) is outside the scroll area. since the function is
visible (1/10th of it anyway), GEF is painting it. there are multiple
such functions visible in this case.
on a large model, without the app-clip optimization there's a multiple
second wait for a redraw-on-scroll to take place. after the
optimization, the latency is sub-second, almost imperceptible.
from what you say, i think the problem is being caused, not by actual
paint operations, but by repeated iteration over many useless points.
plus any copying operations that copy the entire pointlist, most of
which is invisible.
other than eliminating any extra buffer copy(ies) (allow the pointlist
to be specified in the same format as GC expects points so that byte
massage is eliminated), i don't see that there's anything to be done at
the GEF/draw2d level to improve performance.
iterating over the entire pointlist to clip it is a linear time
operation for GEF. so, unless there currently are multiple iterations
over the pointlist, there's not much gained by clipping. for the app,
the clip is a logN operation, because the app knows that it's a 1-1 XY
mapping with a sorted point list. GEF can't make that assumption in the
general case.
perhaps if you introduced a sorted-polyline figure type into draw2d? GEF
could clip this in logN time. that's the only reasonable "solution"
approach at the GEF/draw2d level.
i suspect you haven't run into this issue before because most people are
using GEF in UML diagram'ish apps, where this never comes up.
(in)visibility makes sure that most polylines are never drawn.
i don't view this as something that's really fixable in GEF. eliminating
any unnecessary buffer copies between GEF, draw2d, SWT and the native OS
is something that should probably be done anyway, but it may or may not
help in this case.
app clipping in this instance is completely appropriate. it's not a hack
or workaround. just a somewhat different way to use GEF. and it really
was an easy fix (less than a day even including all related refactoring).
i no longer have a problem, but if you think the buffer copy issue is
one that's worth fixing, i'm happy to raise it.
Pratik Shah wrote:
> Are you handling the case of the polyline going outside the clip area and
> then re-entering it?
>
> What kind of a performance improvement are you noticing? Do your
> connectoins have a lot of bendpoints? Can you reproduce this with the logic
> example? I think the GC doesn't paint anything outside the clip region,
> which is why it's odd that you're noticing a performance drop. Plus, GEF
> doesn't paint any figures that are not visible. If you have a legitimate
> case of a performance problem, you should open a bug report. SWT or Draw2d
> should clip the pointlist if it makes a significant enough difference.
>
|
|
|
Re: polyline not clipping? [message #202173 is a reply to message #201766] |
Mon, 07 November 2005 09:37   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> from what you say, i think the problem is being caused, not by actual
> paint operations, but by repeated iteration over many useless points. plus
> any copying operations that copy the entire pointlist, most of which is
> invisible.
>
> other than eliminating any extra buffer copy(ies) (allow the pointlist to
> be specified in the same format as GC expects points so that byte massage
> is eliminated), i don't see that there's anything to be done at the
> GEF/draw2d level to improve performance.
PointList is in exactly the format used by GC. There are several method on
it to set its capacity or initialize it from an int array, to avoid array
copying.
Since you have sorted data, you should probably make a figure that queries
the clip range and paints only a smaller section of the polyline. BTW, do
you see this performance problem on other platforms? Are you using GTK?
> iterating over the entire pointlist to clip it is a linear time operation
> for GEF. so, unless there currently are multiple iterations over the
> pointlist, there's not much gained by clipping. for the app, the clip is a
> logN operation, because the app knows that it's a 1-1 XY mapping with a
> sorted point list. GEF can't make that assumption in the general case.
>
> i don't view this as something that's really fixable in GEF. eliminating
> any unnecessary buffer copies between GEF, draw2d, SWT and the native OS
> is something that should probably be done anyway, but it may or may not
> help in this case.
If you the PointList API correctly, there is no copying between draw2d and
SWT layer.
|
|
|
Re: polyline not clipping? [message #714803 is a reply to message #201111] |
Thu, 11 August 2011 10:25  |
Eclipse User |
|
|
|
It seems like I'm having the same problem you had and I was wondering if you could share the details of your solution.
I'm using GEF's Polyline figure to display an audio waveform in one of my Eclipse RCP application's view. I'm using a ScrollingGraphicalViewer and a ScalableFreeformRootEditPart as the root edit part. When the polyline has about 1 million points, the initial drawing and all repainting of the figure from there on, specially those caused by scrolling, get really slow. The polyline contains 1 million+ points but only about one thousand of them are displayed at a time.
Based on the description of your solution in this thread, I tried adding a ClippingStrategy to the parent of the Polyline, to explicitly clip the polyline to the section made visible by its parent FreeformViewport object. This approach didn't improve the drawing performance even when setting antialias to SWT.OFF on the Polyline object.
Do you or anyone in this forum have any suggestions for me? Could you please share how you efficiently displayed signals in your application?
Any help will be greatly appreciated
|
|
|
Goto Forum:
Current Time: Tue Apr 29 18:38:17 EDT 2025
Powered by FUDForum. Page generated in 0.09063 seconds
|