Quick fix for openjdk20

[Philip Race]

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