On Sun, 7 Mar 2021 22:31:16 GMT, Sergey Bylokhov <s...@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
