> > FWIW we have just had at a report of a performance drop in JDK 20 from a b07 > change to show how it takes > time for these things to be discovered. Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime).
Best Regards, Alexey > On Dec 7, 2022, at 7:22 PM, Philip Race <philip.r...@oracle.com> wrote: > > This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so > it is a better time for that. > FWIW we have just had at a report of a performance drop in JDK 20 from a b07 > change to show how it takes > time for these things to be discovered. > Also I had a bug / rfe for this a while back : > https://bugs.openjdk.org/browse/JDK-8233037 > I closed it as WNF because I wasn't able to see a performance boost. > > So the right way to do this is to provide some solid evidence of what gets > faster and what gets > slower with a range of different values (not just the JBR one) and re-open > that bug and resolve early in 21. > > -phil. > > > On 12/7/22 7:36 AM, Alexey Ushakov wrote: >> Yes, I confirm that we’ve been using such enlarged buffer for a long time in >> production. It helped us with scrolling performance on 4K monitors. The >> suggested property could help to adjust the buffer for the needs of >> particular application. >> >> Best Regards, >> Alexey >> >>> On 7 Dec 2022, at 11:37, Laurent Bourgès <bourges.laur...@gmail.com >>> <mailto:bourges.laur...@gmail.com>> wrote: >>> >>> Hi, >>> >>> For years, JetBrains Runtime uses a larger render queue buffer size (32kb >>> to 6,400,000 bytes) in production, as it boosted many accelerated >>> pipelines: d3d, ogl, metal : >>> ~ 10 to 20% on large fills... >>> >>> JBR RenderQueue: >>> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 >>> >>> JDK RenderQueue: >>> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75 >>> >>> I want to propose such quick fix in openjdk20 today, as a 1-line fix. >>> >>> >>> /** The size of the underlying buffer, in bytes. */ >>> private static final int BUFFER_SIZE = 6400000; >>> >>> To ensure a smooth transition, I prefer introducing a new >>> sun.java2d.render.queue system property to increase the default (32kb) >>> buffer capacity: >>> >>> See in marlin: >>> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78 >>> >>> So here is my current proposal: >>> [[[ >>> >>> /** The size of the underlying buffer, in bytes. */ >>> private static final int BUFFER_SIZE; >>> >>> static { >>> // Default 32K is too small for high-end GPU: >>> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, >>> 32 * 1024, 16 * 1024 * 1024), 1024); >>> >>> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + >>> BUFFER_SIZE); >>> } >>> >>> // system property utilities >>> public static int getInteger(final String key, final int def, >>> final int min, final int max) >>> { >>> final String property = AccessController.doPrivileged( >>> new GetPropertyAction(key)); >>> >>> int value = def; >>> if (property != null) { >>> try { >>> value = Integer.decode(property); >>> } catch (NumberFormatException e) { >>> System.out.println("Invalid integer value for " + key + " = >>> " + property); >>> } >>> } >>> >>> // check for invalid values >>> if ((value < min) || (value > max)) { >>> System.out.println("Invalid value for " + key + " = " + value >>> + "; expected value in range[" + min + ", " + max + "] >>> !"); >>> value = def; >>> } >>> return value; >>> } >>> >>> protected static int align(final int val, final int norm) { >>> final int ceil = (int)Math.ceil( ((float) val) / norm); >>> return ceil * norm; >>> } >>> ]]] >>> >>> Would you accept such late change for openjdk20 ? >>> >>> Cheers, >>> Laurent Bourgès >> >
