fix for bug 4527745 does not fix the performance for those lines that
require clipping. In other words, the fix works only for lines that
have been clipped *before* calling Graphics.drawLine(). CAP member still
need to specify a runtime property like
when launch JVMs to by pass this performance degradation problem.
This requirement will be difficult to satisfy in large applications such as
Landmark Graphic, which consist of multiple graphics components, all running
in the same JVM. If any critical component fails to pre-clip its lines, then need to set the property above to false. When do this for a simple benchmark, with lines that require clipping, drawing is 20 times faster than when set
this property to true (the default).
Real applications depend on efficient clipping, and a factor of 20 is
significant. 2-D line clipping belongs in graphics systems, not in higher
level components. If Direct3D cannot clip 2D lines efficiently, then systems
higher up, but beneath Graphics.drawLine(), should do so.
Committing to mantis.
The particularly poor performance of unclipped lines is due to punting to
the GDI renderer for those lines. The combination of overhead for GDI
lines and context switching between the DirectX and GDI drivers makes
line performance suffer for applications which have a mix of clipped and
The fix for this is to implement some simple clipping solution for d3d lines,
either in software (determining the endpoints of lines that intersect with
clipping boundaries) or in hardware (setting clip boundaries for d3d).
Handling the simple clip case fixes this test case, bringing the average
rendering time on my laptop down from over 7 seconds to around 200 ms.
The fix was to simply clip each line against the rectangular bounds (still
punting on complex shape clips) and send the lines into d3d. Fixed in mantis.