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

Ajit Ghaisas aghaisas at openjdk.java.net
Thu Jan 7 10:36:04 UTC 2021

On Thu, 7 Jan 2021 07:34:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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.
> If it is unsupported then why you should check that for every device creation? What happens if one device was created using metal and then another device will use OGL?

I have moved the Metal framework availability check to be done only once now.
There is still a check if MTLGraphicsConfig.getConfig() fails by any chance. 

CGraphicsDevice contains GraphicsConfiguration - which is created in the constructor - It can be either MTLGraphicsConfiguration or OpenGLConfiguration. This check needs to be done while creating the config.
For Win32GraphicsDevice - the config is not created in the constructor, but at a later stage in getDefaultConfiguration(). So only the place of checking for OGL or falling back to GDI is different, but the concept is the same.

The whole idea of one device using metal and another device using OGL is hypothetical. The condition check cannot pass for one device and fail for another.


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

More information about the lanai-dev mailing list