RFR: 8258754: Gracefully fallback to the OpenGL rendering pipeline if Metal rendering pipeline initialization fails

Ajit Ghaisas aghaisas at openjdk.java.net
Thu Jan 7 07:28:13 UTC 2021


On Thu, 7 Jan 2021 06:32:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Does this check mean that the MTLRenderQueue.sync() is not a noop if the metal is not enabled?

I don't know how else we will differentiate between Metal and OGL here.
MTLRenderQueue.sync() is still a noop - as there is null instance check inside it.
The comment above the if check has become stale - I will update it.

> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 71:
> 
>> 69: 
>> 70:         // Check whether -Dsun.java2d.metal=true has been specified
>> 71:         if (MacOSFlags.isMetalEnabled()) {
> 
> Is it possible to use metal and OGL at the same time on different devices? I think it is better to move these checks to the CGraphicsEnvironment.makeScreenDevice(), similar Win32GraphicsEnvironment.makeScreenDevice()

I am not sure why someone wants to use different pipelines on different devices? and should we support it?
On Windows we do that as a fallback to overcome a limitation of WGL - that's what I could infer from code in W32GraphicsDevice.getDefaultConfiguration()

I doubt whether we can add these checks in CGraphicsEnvironment.makeScreenDevice() - as we do not have specific MTLGraphicsDevice and CGLGraphicsDevice classes. That's the reason this method is currently unsupported.

Win32GraphicsEnvironment.makeScreenDevice() - creates either D3DGraphicsDevice or Win32GraphicsDevice based on whether isD3DEnabled. 
Win32GraphicsDevice in turn uses either WGLGraphicsConfig or Win32GraphicsConfig based on whether OGL is enabled.

I felt CGraphicsDevice (similar to Win32GraphicsDevice) can differentiate between metal or OGL. Hence, I have added checks here.

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

PR: https://git.openjdk.java.net/lanai/pull/147


More information about the lanai-dev mailing list