Home » Eclipse Projects » GEF » polyline not clipping?
| polyline not clipping? [message #201111] |
Sat, 29 October 2005 08: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 #201140 is a reply to message #201111] |
Sun, 30 October 2005 06:16  |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
yup. that was the problem. once i changed the user code to clip the
polyline manually, the performance issue disappeared.
incidentally, the docs seem to indicate that the SWT Path's _can_ be
clipped. but there doesn't seem to be a draw2d abstraction that
corresponds to the Path as yet.
regards,
|
|
|
| Re: polyline not clipping? [message #201171 is a reply to message #201111] |
Mon, 31 October 2005 00:49 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
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?
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:djvcmg$e5o$1@news.eclipse.org...
> 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] |
Mon, 31 October 2005 02: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 #201256 is a reply to message #201179] |
Mon, 31 October 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> 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
I'm not aware of anything like this. Please point this out to us and provide
us with the benchmark that shows the performance problem.
|
|
|
| Re: polyline not clipping? [message #201444 is a reply to message #201256] |
Tue, 01 November 2005 02:19 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i'm afraid i don't have a benchmark for this (just the actual
application code) at the moment. and won't be able to create one for a
while. apologies.
what i did to diagnose the issue was trace a call to polyline paint into
swt.GC.drawPolyline. the list of points was the entire polyline
pointlist, while i was expecting to see only the clipped points. i
didn't investigate beyond this.
however, i did rewrite the app code to create a different polyline(s)
with only the clipped segments, and called paint on the new line. this
completely removed the performance issue. this was the only change that
was made.
sorry i can't be more helpful.
and as i said, i'm not sure this is a problem, or that it's fixable at
the draw2d level. it's just worth documenting that the application may
need to clip the polyline if there's a performance issue.
>
> I'm not aware of anything like this. Please point this out to us and provide
> us with the benchmark that shows the performance problem.
>
|
|
|
| Re: polyline not clipping? [message #201570 is a reply to message #201444] |
Tue, 01 November 2005 23:58 |
| Eclipse User |
|
|
|
Originally posted by: none.unknown.com
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.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:dk6j8i$4ra$1@news.eclipse.org...
> i'm afraid i don't have a benchmark for this (just the actual
> application code) at the moment. and won't be able to create one for a
> while. apologies.
>
> what i did to diagnose the issue was trace a call to polyline paint into
> swt.GC.drawPolyline. the list of points was the entire polyline
> pointlist, while i was expecting to see only the clipped points. i
> didn't investigate beyond this.
>
> however, i did rewrite the app code to create a different polyline(s)
> with only the clipped segments, and called paint on the new line. this
> completely removed the performance issue. this was the only change that
> was made.
>
> sorry i can't be more helpful.
>
> and as i said, i'm not sure this is a problem, or that it's fixable at
> the draw2d level. it's just worth documenting that the application may
> need to clip the polyline if there's a performance issue.
>
> >
> > I'm not aware of anything like this. Please point this out to us and
provide
> > us with the benchmark that shows the performance problem.
> >
|
|
|
| Re: polyline not clipping? [message #201766 is a reply to message #201570] |
Thu, 03 November 2005 09: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 14: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.
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 08:53:01 GMT 2024
Powered by FUDForum. Page generated in 0.02264 seconds |
] 
Search
Help
Register
Login
Home
