Re: RFR: 8362204: test/jdk/sun/awt/font/TestDevTransform.java fails on Ubuntu 24.04

On Sat, 20 Sep 2025 23:55:39 GMT, Sergey Bylokhov wrote: > This test verifies rendering consistency across three APIs: String, > TextLayout, and GlyphVector. The same text is rendered using each API, and > the results are expected to match. > > The test logic differs slightly between the two c

Re: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]

On Thu, 7 Aug 2025 12:06:02 GMT, Nikita Gubarkov wrote: >> For "true" null objects, reset the ref itself to null. Non-null ref with >> null content means that the object was GC'ed. GC'ed state always behaves as >> not-equal to the new one, causing corresponding ops to be written into RQ. >> >>

Re: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]

On Thu, 7 Aug 2025 11:57:38 GMT, Nikita Gubarkov wrote: >> For wrapping, you can use the following one-liner >> `Optional.ofNullable(val).flatMap(e -> Optional.of(new WeakReference(val)));` > > I don't really understand how this could simplify the check. > For wrapping, instead of `obj == null ?

Re: RFR: 8364434: Inconsistent BufferedContext state after GC

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov wrote: > For "true" null objects, reset the ref itself to null. Non-null ref with null > content means that the object was GC'ed. GC'ed state always behaves as > not-equal to the new one, causing corresponding ops to be written into RQ. > > Alt

Re: RFR: 8364434: Inconsistent BufferedContext state after GC

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov wrote: > For "true" null objects, reset the ref itself to null. Non-null ref with null > content means that the object was GC'ed. GC'ed state always behaves as > not-equal to the new one, causing corresponding ops to be written into RQ. > > Alt

Re: RFR: 8364434: Inconsistent BufferedContext state after GC

On Tue, 5 Aug 2025 13:25:19 GMT, Alexey Ushakov wrote: >> For "true" null objects, reset the ref itself to null. Non-null ref with >> null content means that the object was GC'ed. GC'ed state always behaves as >> not-equal to the new one, causing c

Re: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119)

On Tue, 3 Jun 2025 03:39:31 GMT, Alexander Zvegintsev wrote: > After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a > pending exception. LGTM - Marked as reviewed by avu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25605#pullrequestreview-2891255639

Re: RFR: 8312198: [macos] metal pipeline - window rendering stops after display sleep [v2]

On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V wrote: >> In stress based scenarios it is observed that nothing is drawn in UI content >> when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i >> am not able to reproduce it, but based on details in the bug it looks like

Re: RFR: 8312198: [macos] metal pipeline - window rendering stops after display sleep

On Thu, 22 May 2025 14:30:13 GMT, Jayathirth D V wrote: >> Is it possible that it is somehow related to 8304825? could be the layer >> created "during display sleep" and that might be in "sleep" more that 5 >> seconds? > >> Is it possible that it is somehow related to 8304825? could be the laye

Re: RFR: 8312198: [macos] metal pipeline - window rendering stops after display sleep

On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V wrote: > In stress based scenarios it is observed that nothing is drawn in UI content > when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i > am not able to reproduce it, but based on details in the bug it looks like we

Re: RFR: 8355904: Use variadic macros for J2dTrace [v2]

On Tue, 29 Apr 2025 14:04:07 GMT, Nikita Gubarkov wrote: >> J2dTrace macros have multiple overloads specifying number of arguments, >> making it less convent to change number of arguments. There were cases when >> existing macros were not enough and people had to add new variants with even >>

Re: RFR: 8355904: Use variadic macros for J2dTrace [v2]

On Wed, 30 Apr 2025 06:15:33 GMT, Nikita Gubarkov wrote: >> src/java.desktop/share/native/libawt/java2d/Trace.h line 58: >> >>> 56: #ifndef DEBUG >>> 57: #define J2dTrace(level, ...) >>> 58: #define J2dTraceLn(level, ...) >> >> This looks fine, but maybe the string argument could be included as

Re: RFR: 8354191: GTK LaF should use pre-multiplied alpha same as cairo

On Wed, 9 Apr 2025 14:42:05 GMT, Maxim Kartashev wrote: > The pixels that cairo produces for GTK LaF to draw on a Swing component have > their alpha components pre-multiplied as per [the > documentation](https://www.cairographics.org/manual/cairo-Image-Surfaces.html?spm=a2ty_o01.29997173.0.0.54

Re: RFR: 6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063

On Tue, 11 Feb 2025 01:40:01 GMT, Daniel Gredler wrote: > Expands regression test to cover bug JDK-6562489. > > No additional fix is required after the JDK-8208377 fix (see #22670). The test update looks good to me. - Marked as reviewed by avu (Committer). PR Review: https://git.

Re: RFR: 8341790: Fix ExceptionOccurred in java.desktop

On Fri, 8 Nov 2024 14:45:04 GMT, Laurent Bourgès wrote: > Use ExceptionCheck instead > Removed dead code LGTM - Marked as reviewed by avu (Committer). PR Review: https://git.openjdk.org/jdk/pull/21981#pullrequestreview-2434044353

Re: RFR: 8341793: Fix ExceptionOccurred in jdk.accessibility

On Fri, 8 Nov 2024 14:31:46 GMT, Laurent Bourgès wrote: > Use ExceptionCheck instead LGTM - Marked as reviewed by avu (Committer). PR Review: https://git.openjdk.org/jdk/pull/21979#pullrequestreview-2434054780

Re: Marlin cubic bezier accuracy !

Hi Laurent, Actually part of the work (separating curves into monotonic ones) I've implemented in Java years ago, see ProcessQuad/ProcessCubic https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java I suppose applying some kind of Newton algorit

Re: RFR: 8339341: SurfaceManager cacheMap retains strong references [v4]

On Thu, 19 Sep 2024 11:54:56 GMT, Nikita Gubarkov wrote: >> I moved SurfaceDataProxy cache into a separate class. >> Now caching level is determined by placement of the >> SurfaceManager.ProxyCache object instead of a "proxy key". This cache "owns" >> proxies and therefore strong refs via them

Re: RFR: 8339341: SurfaceManager cacheMap retains strong references [v4]

On Thu, 19 Sep 2024 11:54:56 GMT, Nikita Gubarkov wrote: >> I moved SurfaceDataProxy cache into a separate class. >> Now caching level is determined by placement of the >> SurfaceManager.ProxyCache object instead of a "proxy key". This cache "owns" >> proxies and therefore strong refs via them

Re: RFR: 8335267: [XWayland] move screencast tokens from .awt to .java folder

On Thu, 18 Jul 2024 14:08:35 GMT, Alexander Zvegintsev wrote: > Trivial fix to move the screencast token storage file from > `~/.awt/robot/screencast-tokens.properties` to > `~/.java/robot/screencast-tokens.properties`, where it should be. > Old location is still valid and will only be used if

Re: RFR: 8335267: [XWayland] move screencast tokens from .awt to .java folder

On Thu, 18 Jul 2024 14:08:35 GMT, Alexander Zvegintsev wrote: > Trivial fix to move the screencast token storage file from > `~/.awt/robot/screencast-tokens.properties` to > `~/.java/robot/screencast-tokens.properties`, where it should be. > Old location is still valid and will only be used if

Integrated: 8314498: [macos] Transferring File objects to Finder fails

On Thu, 11 Jul 2024 19:48:00 GMT, Alexey Ushakov wrote: > Here is an updated version of the fix we have used in Jetbrains Runtime for > quite a while. It has been tested by running jdk_desktop tests and manually > using a test case attached to this issue. > There is no reg test

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

On Sat, 13 Jul 2024 19:05:00 GMT, Phil Race wrote: > I wonder whether this could be the basis of an automated regression test .. > can't we get the clipboard contents and verify it is a file ? It works inside java app no matter if the fix was applied. I've spent some time trying to create the t

Re: RFR: 8336382: Fixes error reporting in loading AWT and fonts

On Sat, 13 Jul 2024 00:18:43 GMT, Karm Michal Babacek wrote: > If there is a problem with finding and calling e.g. > `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains > set and it is not cleared. Later, that manifests as: > > Fatal error reported via JNI: Could

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

On Fri, 12 Jul 2024 17:31:29 GMT, Phil Race wrote: >> Alexey Ushakov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8314498: [macos] Transferring File objects to Finder fails >> >> R

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

> content inside the system clipboard. Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8314498: [macos] Transferring File objects to Finder fails Removed unnecessary parameter - Changes: - all: https://git.

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails

On Thu, 11 Jul 2024 20:25:52 GMT, Phil Race wrote: >> Here is an updated version of the fix we have used in Jetbrains Runtime for >> quite a while. It has been tested by running jdk_desktop tests and manually >> using a test case attached to this issue. >> There is no reg test as I've not foun

RFR: 8314498: [macos] Transferring File objects to Finder fails

Here is an updated version of the fix we have used in Jetbrains Runtime for quite a while. It has been tested by running jdk_desktop tests and manually using a test case attached to this issue. There is no reg test as I've not found a reliable way to verify file list content inside the system c

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

On Fri, 29 Sep 2023 19:35:33 GMT, Arik Hadas wrote: >> Credit goes to JetBrain that fixed it in JetBrainsRuntime (commit 24819d9). >> This fix was also cherry-picked to muCommander and was verified on macOS >> 12.6.8 and macOs 13, on X86_64 and on M1. >> >> Reproducer/steps-to-verify: >> 1. Co

Re: RFR: 8280990: [XWayland] XTest emulated mouse click does not bring window to front

On Tue, 28 May 2024 02:25:46 GMT, Alexander Zvegintsev wrote: > Some of the modal tests fail in X11 compatibility mode on Wayland, because a > mouse click emulated with XTEST does not not cause the windows to be > reordered. > > This is a known limitation because these click events do not lea

Re: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) [v5]

On Fri, 9 Feb 2024 21:29:28 GMT, Laurent Bourgès wrote: >> - new executor modes (buffer & volatile) >> - support parallel rendering on several frames and / or screens >> - added robot calibration + optionally use rounded duration to min frame >> latency (120Hz) >> - give more statistics in verbo

Re: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) [v4]

On Thu, 8 Feb 2024 22:12:17 GMT, Laurent Bourgès wrote: >> - new executor modes (buffer & volatile) >> - support parallel rendering on several frames and / or screens >> - added robot calibration + optionally use rounded duration to min frame >> latency (120Hz) >> - give more statistics in verbo

Re: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12) [v3]

On Sat, 3 Feb 2024 14:17:24 GMT, Laurent Bourgès wrote: >> - new executor modes (buffer & volatile) >> - support parallel rendering on several frames and / or screens >> - added robot calibration + optionally use rounded duration to min frame >> latency (120Hz) >> - give more statistics in verbo

Re: RFR: JDK-8323695 RenderPerf (2D) enhancements (23.12)

On Fri, 12 Jan 2024 21:34:32 GMT, Laurent Bourgès wrote: > - new executor modes (buffer & volatile) > - support parallel rendering on several frames and / or screens > - added robot calibration + optionally use rounded duration to min frame > latency (120Hz) > - give more statistics in verbose (

Re: Metal renderer threading issues [macOS]

to get rid of display link threads completely. Best Regards, Alexey > On Oct 14, 2023, at 5:11 PM, Alan Snyder wrote: > > >>> >>> On Oct 10, 2023, at 3:32 AM, Alexey Ushakov >>> wrote: >>> >>> We actually changed this logic in JetBr

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

On Wed, 11 Oct 2023 08:00:27 GMT, Andrey Starovoyt wrote: >> Arik Hadas has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new co

Re: Metal renderer threading issues [macOS]

Hi, We actually changed this logic in JetBrains Runtime and invoke the CVD api only from one thread but still I see multiple display link threads on M2 machines in some rare cases. So it maybe OS related issue. Best Regards, Alexey > On Oct 9, 2023, at 9:27 PM, Philip Race wrote: > > I can't

Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]

On Sat, 30 Sep 2023 02:54:56 GMT, Sergey Bylokhov wrote: >> Arik Hadas has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new com

Re: RFR: 8309756: Occasional crashes with pipewire screen capture on Wayland

On Mon, 12 Jun 2023 21:24:16 GMT, Phil Race wrote: > This fix seems to resolve some occasional crashes in our usage of pipewire > for Wayland screen capture. > See the bug report for more information. Looks good to me - Marked as reviewed by avu (Committer). PR Review: https://gi

Re: RFR: 8308286 Fix clang warnings in linux code [v4]

On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter >> various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional > commit sinc

Re: RFR: 8308875: java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device" is null'

On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev wrote: > 8308875 is a regression after the recent [fix for > 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively > undid a part of [another, older, > change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee69

Re: RFR: 8308286 Fix clang warnings in linux code [v2]

On Mon, 29 May 2023 22:29:26 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter >> various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional > commit sin

Re: RFR: 8308286 Fix clang warnings in linux code

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various > "warnings as errors". > They can be fixed with small changes. I would suggest either disable warnings on per file basis or rewrite problematic code. Disabli

Re: RFR: 8278583: Open source SwingMark - Swing performance benchmark

On Sat, 15 Apr 2023 05:58:51 GMT, Phil Race wrote: > This is the SwingMark performance benchmark. > It is very simplistic by today's standards but has been in use since 1998 > and gives a sense of changes that affect the UI stack not just core Java 2D > tight loop rendering. > It is mostly "as is

Re: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions [v3]

On Thu, 13 Apr 2023 15:37:29 GMT, Maxim Kartashev wrote: >> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly >> frequent operations. When working over the network (remote X session), those >> can take several *seconds* to complete, introducing repeated freezes even >> wh

Re: RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Thu, 6 Apr 2023 14:16:46 GMT, Ajit Ghaisas wrote: > Root cause : The CVDisplayLink used in MTLLayer stops invoking callbacks on > screen sleep and wakeup event. It is found that stop and restart of > CVDisplayLink on these events also does not help. > > Fix : Recreate the CVDisplayLink on s

Re: RFR: 8305667: Some fonts installed in user directory are not detected on Windows

On Wed, 5 Apr 2023 17:03:45 GMT, Nikita Gubarkov wrote: > `data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, > so its size is twice smaller than actual path limit, because paths returned > by `RegEnumValueW` use wide chars. We need to double this limit. Looks good ---

Re: RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Mon, 3 Apr 2023 12:18:34 GMT, Ajit Ghaisas wrote: > on x64 based systems : Swingmark performance is back to normal, but, one of > the J2DBenchmark test shows 20% degradation. @aghaisas what particular test showed the regression, I've tested x64 and aarch64 macs with different tests from J2D

Re: RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov wrote: > Use one display link thread per MTLContext. Adjust the refresh rate with the > current display. OK, let's try Option 1. It still may be useful to recreate CVDisplaylink on the fly, for example if macOS switch GPU from

Withdrawn: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov wrote: > Use one display link thread per MTLContext. Adjust the refresh rate with the > current display. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13230

Re: RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Thu, 30 Mar 2023 06:53:46 GMT, Ajit Ghaisas wrote: >> Use one display link thread per MTLContext. Adjust the refresh rate with the >> current display. > > I tested the test program of this bug and SwingSet2 - with and without > external monitor attached. > - This patch fixes the reported iss

Re: RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

On Wed, 29 Mar 2023 14:39:12 GMT, Alexey Ushakov wrote: > Use one display link thread per MTLContext. Adjust the refresh rate with the > current display. Thanks for the testing. I've run only RenderPerf and only on M1 but it didn't show any regressions (there were some impro

RFR: 8304825: MacOS metal pipeline - window isn't painted if created during display sleep

Use one display link thread per MTLContext. Adjust the refresh rate with the current display. - Commit messages: - 8304825: MacOS metal pipeline - window isn't painted if created during display sleep Changes: https://git.openjdk.org/jdk/pull/13230/files Webrev: https://webrevs.op

Re: RFR: JDK-8304054: Linux: NullPointerException from FontConfiguration.getVersion in case no fonts are installed

On Wed, 15 Mar 2023 16:02:36 GMT, Matthias Baesken wrote: > On Linux Alpine we were running in the jtreg awt tests into a lot of NPEs > like this : > > java.lang.InternalError: java.lang.reflect.InvocationTargetException > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.jav

Re: RFR: JDK-8304054: Linux: NullPointerException from FontConfiguration.getVersion in case no fonts are installed

Originally there were some bundled fonts used as a fallback in such cases. They were removed because of license issues during the transition from closed JDK to open JDK. Maybe it's time to reconsider that decision and provide some license-compatible fonts for that purpose. Best Regards, Alexey On

Re: RFR: 8302687 Implement interfaces and shared code for announcement feature

On Mon, 13 Mar 2023 16:46:10 GMT, Artem Semenov wrote: > This enhancement covers basic API and shared code that should be implemented > for the Accessibility Announcement feature. src/java.desktop/share/classes/sun/swing/AccessibleAnnounceProvider.java line 40: > 38: * messages do not in

Re: RFR: 8301616: Drag & maximize to another monitor places window incorrectly (Windows)

On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov wrote: > The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows > and breaks maximization logic, so reshape window only if it's not maximized. Marked as reviewed by avu (Committer). - PR: https://git.openjdk.o

Re: RFR: 8269806: Emoji rendering on Linux [v17]

On Tue, 31 Jan 2023 16:20:38 GMT, Nikita Gubarkov wrote: >> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 92: >> >>> 90: >>> 91: private static int unicodeToUnits(int unicode, int dstOffset, >>> char[] dst) { >>> 92: if (unicode >= 0x1) { >> >> Why can'

Re: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread [v8]

On Tue, 10 Jan 2023 11:27:50 GMT, Artem Semenov wrote: >> [OutlineRowAccessibility currentAccessibleWithENV:] defines the >> getCurrentComponent method on the AccessibleContext instance of >> AccessibleJTreeNode class, however the call should go through CAccessibility >> so that it is executed

Re: RFR: 8298644 JNI call of getCurrentComponent on a wrong thread [v4]

On Thu, 29 Dec 2022 14:23:40 GMT, Artem Semenov wrote: >> [OutlineRowAccessibility currentAccessibleWithENV:] defines the >> getCurrentComponent method on the AccessibleContext instance of >> AccessibleJTreeNode class, however the call should go through CAccessibility >> so that it is executed

Re: [jdk20] RFR: 8298217: Regressions 30-110% in SwingMark on MacOS, more so on aarch64

On Fri, 16 Dec 2022 15:20:14 GMT, Ajit Ghaisas wrote: > The nature of data plays an important part in rendering performance as noted > in the comment made on > [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) - > https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&pa

Re: Quick fix for openjdk20

gt; On 08-Dec-2022, at 1:50 PM, Alexey Ushakov > <mailto:alexey.usha...@jetbrains.com>> wrote: >> >>> >>> 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

Re: Quick fix for openjdk20

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 pr

Re: Quick fix for openjdk20

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, Laure

Re: RFR: 8269806: Emoji rendering on Linux [v16]

On Thu, 1 Dec 2022 19:38:44 GMT, Nikita Gubarkov wrote: >> It was implemented in JetBrains Runtime a year ago and was ported & >> refactored for this PR >> It includes: >> - Bitmap glyph loading via Freetype >> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or >> bilin

Re: RFR: 8269806: Emoji rendering on Linux [v16]

> That's a real pain how skipped tests just silently pass. Regression tests > should catch regressions, not pretend that everything is OK when they in fact > didn't test anything There are several options to resolve this problem without failing the tests: - you can provide diagnostic message, so

Integrated: 8290344: Start/stop displaysync affects performance in metal rendering pipeline

On Fri, 15 Jul 2022 11:32:20 GMT, Alexey Ushakov wrote: > Reuse displaysync thread for subsequent updates This pull request has now been integrated. Changeset: f766d927 Author: Alexey Ushakov URL: https://git.openjdk.org/jdk/commit/f766d92755276a40f0cdc087db32c285548572fe St

Re: RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline [v2]

> > Stopping DisplayLink once we are done with blitting was used to fix > https://bugs.openjdk.org/browse/JDK-8259038 . I think with displayLink active > count as 4 we might see unnecessary(~4) displayLink callbacks when we just > draw text and leave it as noticed in the bug. But i think th

Re: RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline

On Mon, 1 Aug 2022 17:48:18 GMT, Alexey Ushakov wrote: > > Looking at the RenderPerfTest numbers ClipFlatOvalAA went down .. but > > everything else improved by at the very least a statistically significant > > amount so why did that one test get worse ? > > I'm

Re: RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline [v2]

> Reuse displaysync thread for subsequent updates Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the l

Integrated: 8291266: RenderPerfTest: missing content while rendering some primitives

On Thu, 4 Aug 2022 21:07:02 GMT, Alexey Ushakov wrote: > Do not cause redundant endEncoder calls with batch processing of drawing > primitives This pull request has now been integrated. Changeset: 871b7dab Author:Alexey Ushakov URL: https://git.openjdk.org/jdk/

Re: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS [v2]

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev wrote: >> Java2D's `Disposer` maintains a record of objects to dispose of with the >> help of a collection that isn't thread safe. When `DisposerRecords` objects >> are being added to it at the same time as others are being disposed on the >> To

Re: Question re -Dsun.java2d.cmm possible available options

Hello Alex, This option (-Dsun.java2d.cmm ) was implemented to switch between proprietary Color Management library from Kodak and open source Little CMS during transition JDK to open source (See https://bugs.openjdk.org/browse/JDK-6476534 for more i

Re: RFR: 8291266: RenderPerfTest: missing content while rendering some primitives [v2]

On Fri, 5 Aug 2022 18:01:26 GMT, Alexey Ushakov wrote: >> Do not cause redundant endEncoder calls with batch processing of drawing >> primitives > > Alexey Ushakov has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8291266: RenderPerfTest: missing content while rendering some primitives [v2]

> Do not cause redundant endEncoder calls with batch processing of drawing > primitives Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8291266: RenderPerfTest: missing content while rendering some primitives Added regr

Re: RFR: 8291266: RenderPerfTest: missing content while rendering some primitives

On Thu, 4 Aug 2022 21:07:02 GMT, Alexey Ushakov wrote: > Do not cause redundant endEncoder calls with batch processing of drawing > primitives Looks like the only way is to use Robot. The problem is not reproducible with VolatileImage. I'll try to come up with somethi

RFR: 8291266: RenderPerfTest: missing content while rendering some primitives

Do not cause redundant endEncoder calls with batch processing of drawing primitives - Commit messages: - 8291266: RenderPerfTest: missing content while rendering some primitives Changes: https://git.openjdk.org/jdk/pull/9756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9

Re: RFR: 8269806: Emoji rendering on Linux [v12]

On Mon, 1 Aug 2022 11:01:58 GMT, Nikita Gubarkov wrote: >> It was implemented in JetBrains Runtime a year ago and was ported & >> refactored for this PR >> It includes: >> - Bitmap glyph loading via Freetype >> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or >> bilin

Re: RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline

On Fri, 22 Jul 2022 18:59:21 GMT, Phil Race wrote: > Looking at the RenderPerfTest numbers ClipFlatOvalAA went down .. but > everything else improved by at the very least a statistically significant > amount so why did that one test get worse ? I'm unable to re-run the testing because of a re

Re: RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline

On Wed, 20 Jul 2022 11:00:32 GMT, Ajit Ghaisas wrote: >> Reuse displaysync thread for subsequent updates > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 32: > >> 30: #import "MTLSurfaceData.h" >> 31: #import "JNIUtilities.h" >> 32: #define KEEP_ALIVE_INC 4 > > Why o

RFR: 8290344: Start/stop displaysync affects performance in metal rendering pipeline

Reuse displaysync thread for subsequent updates - Commit messages: - 8290344: Start/stop displaysync affects performance in metal rendering pipeline Changes: https://git.openjdk.org/jdk/pull/9512/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9512&range=00 Issue: https:/

Re: RFR: 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad

On Mon, 4 Jul 2022 15:40:56 GMT, Vladimir Kempik wrote: > Please review this simple patch. When running idea on jdk17 with asan I have > found this buffer overflow. > The code checks the cache for at least one free element, while placing 6 > elements to the cache. > The fix checks the presence

Re: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing performance with metal rendering pipeline [v2]

On Fri, 24 Jun 2022 05:31:33 GMT, Ajit Ghaisas wrote: >> J2DBench test option files attached to >> [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower >> drawing performance on macOS with Metal rendering pipeline as compared to >> OpenGL rendering pipeline. >> >> **Analy

Re: RFR: 8288948: Few J2DBench tests indicate lower primitive drawing performance with metal rendering pipeline

On Wed, 22 Jun 2022 16:32:11 GMT, Ajit Ghaisas wrote: > J2DBench test option files attached to > [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948) indicate lower > drawing performance on macOS with Metal rendering pipeline as compared to > OpenGL rendering pipeline. > > **Analysis :*