Quick fix for openjdk20

[Laurent Bourgès]

Thanks, Phil

I supposed it too late, no problem for openjdk21.

I made a draft PR and tested several sizes on 1 machine:
https://github.com/openjdk/jdk/pull/11569

Of course I can complete later with more tested machines & using j2dbench
if needed.

I can also give ratios... ie gains.

Cheers,
Laurent


Le mer. 7 déc. 2022, 19:22, Philip Race <philip.race at oracle.com> a écrit :

> 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.laurent at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221207/ec022b2d/attachment.htm>