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@plt
▒
0,00% 0,00% java [.]
RegisterPrimitives ▒
0,00% 0,00% Java2D Disposer [.]
SurfaceData_DisposeOps ▒
0,00% 0,00% AWT-EventQueue- [.] memcpy@plt
▒
0,00% 0,00% AWT-EventQueue- [.] calloc@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 <peterhul...@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.r...@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
