<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Ajit,<div><br></div><div>According to the tests you’ve mentioned it’s not a big difference. Looks like we’ve faced with completely different scenario. I’ll try to figure out the main reason of the failure.</div><div><br></div><div>Best Regards,</div><div>Alexey </div><div><div><br><blockquote type="cite"><div>On Dec 8, 2022, at 12:38 PM, Ajit Ghaisas <ajit.ghaisas@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<br>
<div><br>
<blockquote type="cite">
<div>On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <<a href="mailto:alexey.ushakov@jetbrains.com">alexey.ushakov@jetbrains.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<blockquote type="cite">
<div><br>
</div>
<div>FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes<br>
time for these things to be discovered.</div>
</blockquote>
Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (<a href="https://youtrack.jetbrains.com/issue/JBR-4849">https://youtrack.jetbrains.com/issue/JBR-4849</a> ). It was caused by
<a href="https://bugs.openjdk.org/browse/JDK-8288948">https://bugs.openjdk.org/browse/JDK-8288948</a> (that we back ported into OpenJDK17 based runtime). </div>
</div>
</blockquote>
<br>
<div>The details can be found at - </div>
<div><a href="https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772">https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772</a></div>
<div><br>
</div>
<div>Look at the last 3 lines of that comment & attached test results to <a href="https://bugs.openjdk.org/browse/JDK-8288948">https://bugs.openjdk.org/browse/JDK-8288948</a>.</div>
<div>In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read “Integrated graphics card."</div>
<br>
<blockquote type="cite">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div><br>
</div>
<div>Best Regards,</div>
<div>Alexey<br>
<div><br>
<blockquote type="cite">
<div>On Dec 7, 2022, at 7:22 PM, Philip Race <<a href="mailto:philip.race@oracle.com">philip.race@oracle.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>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.<br>
FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes<br>
time for these things to be discovered.<br>
Also I had a bug / rfe for this a while back : <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8233037">
https://bugs.openjdk.org/browse/JDK-8233037</a><br>
I closed it as WNF because I wasn't able to see a performance boost.<br>
<br>
So the right way to do this is to provide some solid evidence of what gets faster and what gets<br>
slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.<br>
<br>
-phil.<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/7/22 7:36 AM, Alexey Ushakov wrote:<br>
</div>
<blockquote type="cite" cite="mid:7C1FA120-8A68-4805-A507-7D7ADF6BDBB1@jetbrains.com">
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.
<div><br>
</div>
<div>Best Regards,</div>
<div>Alexey<br>
<div><br>
<blockquote type="cite">
<div>On 7 Dec 2022, at 11:37, Laurent Bourgès <<a href="mailto:bourges.laurent@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">bourges.laurent@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="auto">Hi,
<div dir="auto"><br>
<div dir="auto">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 :</div>
<div dir="auto">~ 10 to 20% on large fills...</div>
<div dir="auto"><br>
</div>
<div dir="auto">JBR RenderQueue:</div>
<div dir="auto"><a href="https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">JDK RenderQueue:</div>
<div dir="auto"><a href="https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I want to propose such quick fix in openjdk20 today, as a 1-line fix.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<table>
<tbody>
<tr>
<td><br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>/** The size of the underlying buffer, in bytes. */</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>private static final int BUFFER_SIZE = 6400000;</td>
</tr>
<tr>
</tr>
</tbody>
</table>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:</div>
<div dir="auto"><br>
</div>
<div dir="auto">See in marlin:</div>
<div dir="auto"><a href="https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78</a><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">So here is my current proposal:</div>
<div dir="auto">[[[</div>
<div dir="auto">
<table>
<tbody>
<tr>
<td><br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>/** The size of the underlying buffer, in bytes. */</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>private static final int BUFFER_SIZE;</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td><br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>static {</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>// Default 32K is too small for high-end GPU:</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td><br>
</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>// System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);</td>
</tr>
<tr>
</tr>
</tbody>
</table>
<table>
<tbody>
<tr>
<td>}</td>
</tr>
<tr>
</tr>
</tbody>
</table>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"> // system property utilities</div>
<div dir="auto"> public static int getInteger(final String key, final int def,</div>
<div dir="auto"> final int min, final int max)</div>
<div dir="auto"> {</div>
<div dir="auto"> final String property = AccessController.doPrivileged(</div>
<div dir="auto"> new GetPropertyAction(key));</div>
<div dir="auto"><br>
</div>
<div dir="auto"> int value = def;</div>
<div dir="auto"> if (property != null) {</div>
<div dir="auto"> try {</div>
<div dir="auto"> value = Integer.decode(property);</div>
<div dir="auto"> } catch (NumberFormatException e) {</div>
<div dir="auto"> System.out.println("Invalid integer value for " + key + " = " + property);</div>
<div dir="auto"> }</div>
<div dir="auto"> }</div>
<div dir="auto"><br>
</div>
<div dir="auto"> // check for invalid values</div>
<div dir="auto"> if ((value < min) || (value > max)) {</div>
<div dir="auto"> System.out.println("Invalid value for " + key + " = " + value</div>
<div dir="auto"> + "; expected value in range[" + min + ", " + max + "] !");</div>
<div dir="auto"> value = def;</div>
<div dir="auto"> }</div>
<div dir="auto"> return value;</div>
<div dir="auto"> }</div>
<div dir="auto"><br>
</div>
<div dir="auto"> protected static int align(final int val, final int norm) {</div>
<div dir="auto"> final int ceil = (int)Math.ceil( ((float) val) / norm);</div>
<div dir="auto"> return ceil * norm;</div>
<div dir="auto"> }</div>
<div dir="auto">]]]</div>
<div dir="auto"><br>
</div>
<div dir="auto">Would you accept such late change for openjdk20 ?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Cheers,</div>
<div dir="auto">Laurent Bourgès </div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div></blockquote></div><br></div></body></html>