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.r...@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 > >
