Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
> **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. > The entire work on this was done under [OpenJDK Project - > Lanai](http://openjdk.java.net/projects/lanai/) > > We iterated through several Early Access (EA) builds and have reached a stage > where it is ready to be integrated to openjdk/jdk. The latest EA build is > available at - https://jdk.java.net/lanai/ > > A new option -Dsun.java2d.metal=true | True needs to be used to use this > pipeline. > > **Testing :** > This implementation has been tested with the tests present at - [Test Plan > for JEP 382: New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) > > **Note to reviewers :** > 1) Default rendering pipeline on macOS has not been changed by this PR. > OpenGL still stays as the default rendering pipeline and Metal rendering > pipeline is optional to choose. > > 2) To apply and test this PR - > To enable the metal pipeline you must specify on command line > -Dsun.java2d.metal=true (No message will be printed in this case) or > -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is > enabled gets printed) Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Lanai PR#175 - 8261304 - aghaisas - Changes: - all: https://git.openjdk.java.net/jdk/pull/2403/files - new: https://git.openjdk.java.net/jdk/pull/2403/files/8ed7b5f5..6044adc0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=01-02 Stats: 32 lines in 10 files changed: 0 ins; 12 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403 PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Fri, 5 Feb 2021 18:42:02 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Lanai PR#175 - 8261304 - aghaisas > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894: > >> 892: SHADERS_SUPPORT_DIR := >> $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui >> 893: SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air >> 894: SHADERS_LIB := $(INSTALL_LIBRARIES_HERE)/shaders.metallib > > Q: Should 2d (or awt) be in the name of this file, or is a generic name OK? I think, a generic name is OK as the path of shader file already has both awt (libawt_lwawt) and java2d in it. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 13:40:22 GMT, Ajit Ghaisas wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894: >> >>> 892: SHADERS_SUPPORT_DIR := >>> $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui >>> 893: SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air >>> 894: SHADERS_LIB := $(INSTALL_LIBRARIES_HERE)/shaders.metallib >> >> Q: Should 2d (or awt) be in the name of this file, or is a generic name OK? > > I think, a generic name is OK as the path of shader file already has both awt > (libawt_lwawt) and java2d in it. In the source tree, yes, but not in the jdk image where it ends up in `$JAVA_HOME/lib/shaders.metallib`. I don't have a problem with this, as long as it is a deliberate decision. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8261231: Windows IME was disabled after DnD operation
On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov wrote: > The function InvokeInputMethodFunction() is responsible for invocation of IME > API. Typically it uses PostMessage() to execute corresponding IME function on > the toolkit thread but if DnD operation takes place SendMessage() is used. > The state of m_inputMethodWaitEvent event object remains signalled after > SendMessage() execution. That causes failure of subsequent IME functions > calls via PostMessage(). > > Fix: > SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() > should be synchronised. The state of m_inputMethodWaitEvent event object must > be reseted right after SendMessage() execution. Change looks good and i haven't found any side-effects during testing. Could you please add the label to the bug noting reason for absence of the regression test, like noreg-hard or something? - Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2448
Re: RFR: 8261231: Windows IME was disabled after DnD operation
On Mon, 8 Feb 2021 16:51:21 GMT, Alexander Zuev wrote: >> The function InvokeInputMethodFunction() is responsible for invocation of >> IME API. Typically it uses PostMessage() to execute corresponding IME >> function on the toolkit thread but if DnD operation takes place >> SendMessage() is used. The state of m_inputMethodWaitEvent event object >> remains signalled after SendMessage() execution. That causes failure of >> subsequent IME functions calls via PostMessage(). >> >> Fix: >> SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() >> should be synchronised. The state of m_inputMethodWaitEvent event object >> must be reseted right after SendMessage() execution. > > Change looks good and i haven't found any side-effects during testing. Could > you please add the label to the bug noting reason for absence of the > regression test, like noreg-hard or something? I also tested this fix. It worked fine. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/2448
Re: RFR: 8261231: Windows IME was disabled after DnD operation
On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov wrote: > The function InvokeInputMethodFunction() is responsible for invocation of IME > API. Typically it uses PostMessage() to execute corresponding IME function on > the toolkit thread but if DnD operation takes place SendMessage() is used. > The state of m_inputMethodWaitEvent event object remains signalled after > SendMessage() execution. That causes failure of subsequent IME functions > calls via PostMessage(). > > Fix: > SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() > should be synchronised. The state of m_inputMethodWaitEvent event object must > be reseted right after SendMessage() execution. Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2448
Re: RFR: 8261231: Windows IME was disabled after DnD operation
On Mon, 8 Feb 2021 16:51:21 GMT, Alexander Zuev wrote: > Change looks good and i haven't found any side-effects during testing. Could > you please add the label to the bug noting reason for absence of the > regression test, like noreg-hard or something? Thank you for the review. I have added noreg-hard to the bug - PR: https://git.openjdk.java.net/jdk/pull/2448
Integrated: 8261231: Windows IME was disabled after DnD operation
On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov wrote: > The function InvokeInputMethodFunction() is responsible for invocation of IME > API. Typically it uses PostMessage() to execute corresponding IME function on > the toolkit thread but if DnD operation takes place SendMessage() is used. > The state of m_inputMethodWaitEvent event object remains signalled after > SendMessage() execution. That causes failure of subsequent IME functions > calls via PostMessage(). > > Fix: > SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() > should be synchronised. The state of m_inputMethodWaitEvent event object must > be reseted right after SendMessage() execution. This pull request has now been integrated. Changeset: d6d5d9bf Author:Dmitry Markov URL: https://git.openjdk.java.net/jdk/commit/d6d5d9bf Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod 8261231: Windows IME was disabled after DnD operation Reviewed-by: kizune, serb - PR: https://git.openjdk.java.net/jdk/pull/2448
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Sat, 6 Feb 2021 00:53:08 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Lanai PR#175 - 8261304 - aghaisas > > The file in `RenderPerfTest` should have a GPLv2 license header (no > Classpath). I filed > [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also > highlighted a couple examples below. General comment - I am not sure I like the `MTL` prefix acronym in names (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`). I think you tried to match the `CGL`, but that is a real acronym that stands for "Core Graphics Layer" (I think). `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I suppose, but also just `Metal` would work just fine. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote: >> The file in `RenderPerfTest` should have a GPLv2 license header (no >> Classpath). I filed >> [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also >> highlighted a couple examples below. > > General comment - I am not sure I like the `MTL` prefix acronym in names (ex. > `sun.java2d.metal.MTLVolatileSurfaceManager`). > > I think you tried to match the `CGL`, but that is a real acronym that stands > for "Core Graphics Layer" (I think). > > `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I > suppose, but also just `Metal` would work just fine. I'm in the process of reviewing this feature, but there is lots of code to go through - please wait for my review. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote: > General comment - I am not sure I like the `MTL` prefix acronym in names (ex. > `sun.java2d.metal.MTLVolatileSurfaceManager`). > > I think you tried to match the `CGL`, but that is a real acronym that stands > for "Core Graphics Layer" (I think). > > `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I > suppose, but also just `Metal` would work just fine. `MTL` is the abbreviation that Apple uses for Metal in all of their APIs. The only potential issue I might see with this prefix is in the native code where there could be name collisions between Java2D's names and Apple's names. Since we haven't run into such a collision, I don't think this needs to change, and wouldn't necessarily affect the Java class names anyway. If we were to consider it, `METAL` seems better than `ML` (which is too short to be descriptive and might suggest machine learning). - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) > > Ajit Ghaisas has updated the pull request incrementally with one additional > commit since the last revision: > > Lanai PR#175 - 8261304 - aghaisas > > General comment - I am not sure I like the `MTL` prefix acronym in names > > (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`). > > I think you tried to match the `CGL`, but that is a real acronym that > > stands for "Core Graphics Layer" (I think). > > `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I > > suppose, but also just `Metal` would work just fine. > > `MTL` is the abbreviation that Apple uses for Metal in all of their APIs. The > only potential issue I might see with this prefix is in the native code where > there could be name collisions between Java2D's names and Apple's names. > Since we haven't run into such a collision, I don't think this needs to > change, and wouldn't necessarily affect the Java class names anyway. If we > were to consider it, `METAL` seems better than `ML` (which is too short to be > descriptive and might suggest machine learning). If Apple itself uses `MTL` then we are good. src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java line 35: > 33: > 34: import sun.java2d.SurfaceData; > 35: import sun.java2d.opengl.CGLLayer; Not needed import anymore? src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 113: > 111: // This indicates fallback to other rendering pipeline also > failed. > 112: // Should never reach here > 113: throw new InternalError("Error - unable to initialize any > rendering pipeline."); There is no software based renderer to fall back here? src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 66: > 64:propString.equals("f") || > 65:propString.equals("False") || > 66:propString.equals("F")) Shouldn't `1` and `0` be also allowed here? src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 100: > 98: oglState = PropertyState.ENABLED; // Enable > default pipeline > 99: metalState = PropertyState.DISABLED; // Disable > non-default pipeline > 100: } This matches JEP 382 specification, but even when both GL is `false` and Metal is `false` we still get GL? There is no software based pipeline anymore? src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 131: > 129: @Native > 130: static final int CAPS_EXT_GRAD_SHADER = (FIRST_PRIVATE_CAP << > 3); > 131: /** Indicates the presence of the GL_ARB_texture_rectangle > extension. */ Reference to `GL_ARB_texture_rectangle` extension in Metal pipeline? src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 134: > 132: @Native > 133: static final int CAPS_EXT_TEXRECT = (FIRST_PRIVATE_CAP << > 4); > 134: /** Indicates the presence of the GL_NV_texture_barrier > extension. */ Reference to `GL_NV_texture_barrier` extension in Metal pipeline? src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 97: > 95: public static void disposeGraphicsConfig(long pConfigInfo) { > 96: MTLRenderQueue rq = getInstance(); > 97: rq.lock(); Is it allowed to have multiple `MTLRenderQueue` instances? If not, then I see this pattern everywhere: MTLRenderQueue rq = getInstance(); rq.lock(); { ... } rq.unlock(); why not just do: MTLRenderQueue.
RFR: 8261368: The new TestNullSetColor test is placed in the wrong group
The test is moved to the "java/awt/Graphics/" since it validates behavior of the java.awt.Graphics$setColor() method. - Commit messages: - Update TestNullSetColor.java Changes: https://git.openjdk.java.net/jdk/pull/2467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261368 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2467/head:pull/2467 PR: https://git.openjdk.java.net/jdk/pull/2467
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) > > Ajit Ghaisas has updated the pull request incrementally with one additional > commit since the last revision: > > Lanai PR#175 - 8261304 - aghaisas Changes requested by gziemski (Committer). src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 61: > 59: > 60: public abstract class MTLSurfaceData extends SurfaceData > 61: implements AccelSurface { `MTLSurfaceData` and `OGLSurfaceData` seem to share lots of the same code, isn't there a way to refactor the common code out? There are other files that structually look identical, except for the names of classes they use, ex `MTLMaskBlit.java` and `OGLMaskBlit.java`. - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: RFR: 8261368: The new TestNullSetColor test is placed in the wrong group
On Mon, 8 Feb 2021 22:41:01 GMT, Sergey Bylokhov wrote: > The test is moved to the "java/awt/Graphics/" since it validates behavior of > the java.awt.Graphics$setColor() method. Marked as reviewed by kizune (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2467
Integrated: 8261368: The new TestNullSetColor test is placed in the wrong group
On Mon, 8 Feb 2021 22:41:01 GMT, Sergey Bylokhov wrote: > The test is moved to the "java/awt/Graphics/" since it validates behavior of > the java.awt.Graphics$setColor() method. This pull request has now been integrated. Changeset: 5d8204b1 Author:Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/5d8204b1 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8261368: The new TestNullSetColor test is placed in the wrong group Reviewed-by: kizune - PR: https://git.openjdk.java.net/jdk/pull/2467
Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v3]
On Mon, 8 Feb 2021 14:22:27 GMT, Kevin Rushforth wrote: >> I think, a generic name is OK as the path of shader file already has both >> awt (libawt_lwawt) and java2d in it. > > In the source tree, yes, but not in the jdk image where it ends up in > `$JAVA_HOME/lib/shaders.metallib`. I don't have a problem with this, as long > as it is a deliberate decision. OK. I get your point. Keeping the name unchanged for now as there won't be another .metallib in JDK. The name can be changed in the future if need arises. - PR: https://git.openjdk.java.net/jdk/pull/2403