Quick fix for openjdk20

Alexey Ushakov alexey.ushakov at jetbrains.com
Wed Dec 7 15:36:13 UTC 2022


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 <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 <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 <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/ebaed7cf/attachment.htm>


More information about the client-libs-dev mailing list