Community
Participate
Working Groups
The squiggles drawing strategy together with enabled margin painter degrades drawing performance for long lines. To reproduce: - change drawing strategy of bookmarks to squiggles - create a simple text file with a long line (~ 4000 characters) - enable the print margin painter - create a bookmark on the long line - observe sluggish drawing (and very high CPU usage) Interestingly, enabling the margin painter after creating the bookmark does not degrade performance.
http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm
Created attachment 48953 [details] Test project Steps to reproduce: - import test project into a workspace using plain Eclipse SDK - import preferences file "preferences.epf" contained in the project - open file "longline.txt" with default Eclipse Text Editor - create a bookmark on line 4 - type text into line 4
Created attachment 48955 [details] Thread dumps while busy drawing
I did not test other platforms, but it definitely happens on - Windows XP SP 1 - Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) - Eclipse SDK 3.2 (Build id: M20060629-1905)
Can reproduce now. The problem is that normally the GC's line width is 0 which means "use fastest possible algorithm". The MarginPainter sets this to 1 since it wants to have 1 pixel width guaranteed. Using 1 seems to bring the performance of drawPolyline(...) down to the knees. If e.g. 5 is used it is even worse. We now explicitly set the GC's line with to 0 when drawing the squiggles. Moving to SWT to investigate the performance problem.
If you want to draw the fastest possible line, you should use line width zero. On X (and some other graphics systems), this tells the graphics subsystem to optimize the line drawing as much as possible, making use of any special drivers. However, the output might not be identical to the same line drawn with line width one (but both lines will be one pixel wide). Having said all that, we still might have a performance problem here.
>If you want to draw the fastest possible line, you should use line width zero. Yep, that's what we now ensure to be used for the squiggles painter but the print margin painter has API to set the width. >However, the output might not be identical to the same line drawn >with line width one (but both lines will be one pixel wide). So, they will both we 1 but how would they differ then? Does it mean that width 0 can override the line style then?
No it means that on X for example, the actual pixels that are drawn may vary. When the width is one, X uses "slow code" that follows a well know algorithm, making sure the pixels are the same between two different X platforms. When the width is zero, X is free to use "optimized code" in the driver. I'm a bit surprised that Windows does this sort of thing too and suspect our code. That's why I didn't close this bug report.
There is nothing that SWT can do about this. If a PS_GEOMETRIC pen needs to be used, it will be alot slower than a PS_COSMETIC pen. PS_COSMETIC can be used with line widths other than 0, but the following properties have true as well: cap=SWT.CAP_ROUND join=SWT.JOIN_ROUND dashes=null style=SWT.LINE_SOLID
According to your explanation this is then either WONTFIX or INVALID since I just explained that you also see the degradation. WORKSFORME indicates that you could not reproduce what got reported. Maybe a hint in Javadoc that even using 1 pixel instead of fastest can have this non-minor performance impact?
I guess I was trying to say WORKASEXPECTED. The note is already in the javadoc for setLineWidth().
closing again.
