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

[Laurent Bourgès]

Phil,

It reminds me I have rewritten in Marlin renderer the crossing sort at
every scanline.
Pisces was using a trivial insertion sort but it became very slow when the
crossing count is large.
I adopted a special merge sort as crossings are mostly ordered: big win.

What sort algo is in action in drawPolyLine ?

Cheers,
Laurent

Le ven. 12 oct. 2018 à 01:15, Phil Race <philip.race at oracle.com> a écrit :

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20181012/31fb034d/attachment.html>