In my previous email I was asking only about the "older" system,
precisely because as you confirm below, I wanted to know that
it was operating on an unscaled graphics.
It is being triggered by the scale. If you add :
graphics.scale(1.25, 1.25)
in your application and run on 8 you'll see the window size is
not changed but the contents are and the test now runs slowly
like the JDK 9+ case.
I think most primitives (text, images, fills, gradients, untransformed
rectangle drawing) will be only slightly slower. The same if
you were drawing anti-aliased lines - they are going to be slow already
by comparison.
A few similar primitives (drawArc, drawOval, drawPolygon ..) may be
similarly
affected but drawPolyLine even has dedicated loops for single pixel wide
lines
so may be the most affected when these loops can't be used.
So this is a kind of worse case difference. Untransformed, aliased lines
are super fast.
Once you do anything like add anti-aliasing or a transform, they get slower.
Note: hidpi does not mean that acceleration is "turned off", rather that
some operations can no longer be sent to the accelerated pipeline, either
it doesn't support that mode, or we haven't implemented the necessary code
to invoke it for that mode.
In Peter's case on Intel there will be no acceleration, since we do not
enable D3D
on Intel graphics cards. But on my system the time is identical whether
I use D3D or not.
But there is something else going on here too.
Peter's test use 2^16 line segments.
On my windows system at 1.25 scale, this takes 55 seconds to run.
But 2^15 line segments completes in 10 seconds.
So 2 x the no. of lines takes approx 5 times as long to run ..
I have a modified version of Peter's program which breaks the polyline array
into subarrays which get passed to multiple calls to drawPolyline.
It misses joining the last point in ARR[N] to the first point in
ARR[N+1] but
I think that should not make much difference but if someone wants to use
that in a real app they'll need to handle it.
What I see is that using the smaller arrays makes a big difference.
So instead of 60 seconds to draw one 65,536 element polyline, to
draw 64 polylines of 1,024 elements takes just 1.1 seconds.
Still not 0.05 but better.
From what I can see it is being turned into a huge GeneralPath and
rendered as a Shape. Multiple smaller shapes perform better.
Perhaps we can add a loop that is specific to polygons that will handle
this better, but that isn't likely to be jumped on .. and obviously
it will never be *as* fast as narrow lines.
-phil.
On 10/11/2018 04:26 AM, Peter Hull wrote:
Hi Laurent,
Thanks for the detailed explanation. I quickly checked on the older
Windows system and the Java 11 window was the same size as the Java 8
one, implying no scaling was going on (I guess just because it has a
lower resolution monitor) - so that confirms your hypothesis.
If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
matter if the window is a bit small. However I believe some higher end
systems have much higher scaling factors (2x, 3x?). Is there a general
way to specify a 1px line regardless of scaling, because in my case I
don't mind too much if it's a 'hair-line'?
By the way, my actual application doesn't have 65000 lines but it
draws 3 graphs with about 3000 points, which makes it noticeably slow
when resizing the Window. I suppose I should look into cutting down
the number of points somehow...
Pete
