[OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v10]

Alexey Ushakov avu at openjdk.java.net
Tue Mar 9 22:21:44 UTC 2021


On Sun, 7 Mar 2021 22:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/2f09d382...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java line 44:
> 
>> 42: 
>> 43:     // Pass the insets to native code to make adjustments in blitTexture
>> 44:     private static native void nativeSetInsets(long layerPtr, int top, int left);
> 
> Probably I have asked this already, but why we need to use insets? Why insets is not necessary for ogl?

We have different coordinate systems for OGL and Metal. Metal (0,0) for textures is the top-left corner whereas OGL (0,0) is the bottom-left one, so we need to have insets to perform blitting to drawable correctly.

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 499:
> 
>> 497:         }
>> 498: 
>> 499:         // We can convert argb_pre data from MTL surface in two places:
> 
> Does anybody check that this is true for the metal pipeline? or It is just copied from the OGL?

I fixed some conversion logic within JDK-8256331.

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 168:
> 
>> 166:         }
>> 167: 
>> 168:         ContextCapabilities caps = new MTLContext.MTLContextCaps(
> 
> CAPS_DOUBLEBUFFERED is not included?

JDK-8263306

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 146:
> 
>> 144:                 return MTLSurfaceRTT;
>> 145:             default:
>> 146:                 return MTLSurface;
> 
> Do we really support 3 different types of surface? I guess only two of them are different: textures used for manageable images, and surfaces used by the volatile image.

It's true but I don't see any problem returning a more generic type as a default here

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 221:
> 
>> 219:     protected native boolean initRTexture(long pData, boolean isOpaque, int width, int height);
>> 220: 
>> 221:     protected native boolean initFlipBackbuffer(long pData);
> 
> flip back buffer is supported?

No, it should be removed (JDK-8263312)

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m line 284:
> 
>> 282:  */
>> 283: jboolean
>> 284: MTLSD_InitMTLWindow(JNIEnv *env, BMTLSDOps *bmtlsdo)
> 
> When the MTLWindow is used?

MTLContext setSurfacesEnv

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 109:
> 
>> 107: #define MTLSD_TEXTURE         sun_java2d_pipe_hw_AccelSurface_TEXTURE
>> 108: #define MTLSD_FLIP_BACKBUFFER sun_java2d_pipe_hw_AccelSurface_FLIP_BACKBUFFER
>> 109: #define MTLSD_RT_TEXTURE        sun_java2d_pipe_hw_AccelSurface_RT_TEXTURE
> 
> Only two of them are supported? MTLSD_TEXTURE and MTLSD_RT_TEXTURE?

Also, MTLSD_WINDOW is supported

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403


More information about the 2d-dev mailing list