-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
1.4.0
-
Fix Understood
-
x86, sparc
-
solaris_7, windows_nt
From Jeannette as to why drawing lines is so much slower than fillRect:
It's very SLOWWWWW.... Wide lines have to go through a different path --
it goes through the Ductus rasterizer by first getting the outline of
the shape and then rendering it in small sections. (Remember, we have to
deal with arbitrary stroke objects on a wide line so this is the default
path for it.) If we knew that we just had a rectangle, we can go to
an accelerated path that can quickly render to the surface.
Look at the following numbers on an Solaris system (results are probably
somewhat similar on windows):
10 pixel long thin line 3.6 Million/sec
100 pixel long thin line 516 Thousand/sec
10 pixel long wide (lw=10) line 108 Thousand/sec
100 pixel long wide (lw=10) line 35 Thousand/sec
That's a performance drop of about 36x for the 10 pixel lines and
about 15x for the 100 pixel lines. These results are pure X11, not Java.
This shows that most rendering systems have performance issues with wide lines
and we are not an exception.
It's very SLOWWWWW.... Wide lines have to go through a different path --
it goes through the Ductus rasterizer by first getting the outline of
the shape and then rendering it in small sections. (Remember, we have to
deal with arbitrary stroke objects on a wide line so this is the default
path for it.) If we knew that we just had a rectangle, we can go to
an accelerated path that can quickly render to the surface.
Look at the following numbers on an Solaris system (results are probably
somewhat similar on windows):
10 pixel long thin line 3.6 Million/sec
100 pixel long thin line 516 Thousand/sec
10 pixel long wide (lw=10) line 108 Thousand/sec
100 pixel long wide (lw=10) line 35 Thousand/sec
That's a performance drop of about 36x for the 10 pixel lines and
about 15x for the 100 pixel lines. These results are pure X11, not Java.
This shows that most rendering systems have performance issues with wide lines
and we are not an exception.
- duplicates
-
JDK-4474205 Various JProgressBar Painting problems in Windows L&F
- Closed