[OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

[Laurent Bourgès]

Hi Peter,

I confirm that HiDPI support is causing your problem.

On linux (xrender), I added -Dsun.java2d.uiScale=2.5 and the performance
becomes poor ~ 3.3s vs 0.03s !

java -Dsun.java2d.uiScale=2.5 -DuseAA=false -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 1:02:00 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,781s
oct. 11, 2018 1:02:03 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,003s
oct. 11, 2018 1:02:06 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 3,318s*

java -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,073s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,037s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 0,029s*


I enabled antialiasing hint to use Marlin renderer and performance is
slightly better ~1.9s vs 3.3s.
Java: 11 11+28
oct. 11, 2018 1:01:27 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 2,304s
oct. 11, 2018 1:01:29 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 1,911s
oct. 11, 2018 1:01:31 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 1,881s*

Moreover, your polyline is very complicated (65K segments) so AWT (c code)
may have troubles in contrary to the Marlin renderer (pure java - AA
optimized code), that is faster and performs AA computations (8 times more
sampling).

I performed quick profiling using linux perf:
perf record -g java -Dsun.java2d.uiScale=2.5 -jar dist/PolylineTest.jar

Samples: 58K of event 'cycles:ppp', Event count (approx.): 48668354960,
DSO: libawt.so
  Children      Self  Command
Symbol                                                                  ◆


*+   74,35%     0,00%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_nextSpan                     ▒+
74,35%    74,10%  AWT-EventQueue-  [.]
ShapeSINextSpan                                                     ▒+
10,00%     0,05%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_lineTo                       ▒*
     0,22%     0,22%  AWT-EventQueue-  [.]
sortSegmentsByLeadingY                                              ▒
     0,14%     0,14%  AWT-EventQueue-  [.]
appendSegment                                                       ▒
     0,08%     0,00%  java             [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_initIDs                  ▒
     0,04%     0,04%  AWT-EventQueue-  [.]
subdivideLine.isra.0                                                ▒
     0,03%     0,00%  java             [.]
AWT_OnLoad                                                          ▒
     0,03%     0,00%  java             [.]
AWTIsHeadless                                                       ▒
     0,02%     0,02%  AWT-EventQueue-  [.]
GetSpanData                                                         ▒
     0,02%     0,00%  java             [.]
Java_sun_java2d_SurfaceData_initIDs                                 ▒
     0,01%     0,00%  AWT-EventQueue-  [.]
initSegmentTable                                                    ▒
     0,01%     0,00%  java             [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_registerNativeLoops      ▒
     0,01%     0,01%  AWT-EventQueue-  [.] free at plt
▒
     0,00%     0,00%  java             [.]
RegisterPrimitives                                                  ▒
     0,00%     0,00%  Java2D Disposer  [.]
SurfaceData_DisposeOps                                              ▒
     0,00%     0,00%  AWT-EventQueue-  [.] memcpy at plt
▒
     0,00%     0,00%  AWT-EventQueue-  [.] calloc at plt
▒
     0,00%     0,00%  java             [.]
InitSimpleTypes.constprop.0                                         ▒
     0,00%     0,00%  java             [.]
MapAccelFunction                                                    ▒
     0,00%     0,00%  java             [.]
Java_sun_java2d_pipe_SpanClipRenderer_initIDs                       ▒

I suspect that HiDPI implies software rendering instead of accelerated
rendering (xrender drawline, AFAIR).

However, I am not sure such performance issue can be fixed any time soon.
Workaround: use -Dsun.java2d.uiScale=1.0

Regards,
Laurent

Le jeu. 11 oct. 2018 à 10:30, Peter Hull <peterhull90 at gmail.com> a écrit :

> I can answer part of that, but I can't get access to the older system just
> now.
>
> On Wed, Oct 10, 2018 at 4:41 PM Philip Race <philip.race at oracle.com>
> wrote:
> > In other words does
> >
> > -Dsun.java2d.uiScale=1.0
> >
> > even change the physical size of the window on JDK 9/10/11 ?
> >
> Yes, because I can run the same jar under Java 8 and 11. Without the
> scale option, the Java 11 window is bigger than the Java 8 one, by
> about 1.25x (this corresponds to my system setting)
> When I add the scale=1 option to both, they are both the same size
> (and the same as JDK8 without any scaling)
> I've attached 2 images so you can see what I mean, one is without any
> scale option (and I labelled the approx size on this) and the other is
> with -Dsun.java2d.uiScale=1.0.
> The window title contains the system property "java.runtime.version"
> so you can see which is which.
>
> I do appreciate your help on this. It looks like it's coming down to
> Intel's graphics driver, do you agree?
>
> Pete
>


-- 
-- 
Laurent Bourgès
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181011/4798aea3/attachment.html>