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

[Ajit Ghaisas]

On Sat, 16 Jan 2021 00:38:04 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> _Mailing list message from [Alexey Ushakov](mailto:alexey.ushakov at jetbrains.com) on [lanai-dev](mailto:lanai-dev at openjdk.java.net):_
>>> 
>>> Hi Ajit,
>>> 
>>> Let?s have some refactoring here.
>>> 
>>> We have two places this:
>>> 
>>> 107 surfaceData = (CGraphicsDevice.usingMetalPipeline()) ?
>>> 
>>> 108 ((MTLLayer)windowLayer).replaceSurfaceData() :
>>> 109 ((CGLLayer)windowLayer).replaceSurfaceData()
>>> 110 ;
>>> 111 return surfaceData;
>>> 112 }
>>> 
>>> I think it would be better to have a common superclass for CGLayer and MTLLayer with common methods replaceSurfaceData(), getPointer().
>>> 
>>> public class CFLayer extends CFRetainedResource {
>>> ?
>>> public long getWindowLayerPtr() {}
>>> 
>>> public SurfaceData replaceSurfaceData() {}
>>> ...
>>> }
>>> 
>>> So, we can get rid of (CGraphicsDevice.usingMetalPipeline()) ? ? : ? checks
>>> 
>>> Best Regards,
>>> Alexey
>> 
>> Thanks Alexey for this suggestion.
>> Yes. It will simplify the code. This PR is about implementing the fallback mechanism. Once that is in place, we can handle the runtime pipeline selection pattern correction under JDK-8226384.
>
> Conceptually, having an ordered list of the (two) pipelines makes sense (it's what we did for JavaFX with the "prism.order" property).
> 
> For Java2D, in order to fit with existing pattern and existing property names used on other platforms, we will need to stick with the separate properties as defined in this PR.
> 
> Ultimately, Phil gets to decide this, but at a high level here is what I recommend (I think it's pretty much what Ajit's latest patch intends to do, although I haven't looked at the latest changes in enough detail to be sure that's what it does).
> 
> 1. If no properties are specified, try the default pipeline first and "fall back" to the optional pipeline if the default isn't available.
> 
> 2. If exactly one of sun.java2d.opengl or sun.java2d.metal is set to true, then try that pipeline first and the other one as a fallback.
> 
> 3. If exactly one of sun.java2d.opengl or sun.java2d.metal is set to false, then try the other one first and that one last.
> 
> 4. If both are set to true or both are set to false, print a warning and ignore the properties entirely (i.e., use the default).
> 
> The following pseudo-code illustrates this:
> 
>     // default pipeline order
>     pipelineOrder = { OPENGL, METAL };
> 
>     if ("sun.java2d.opengl" and "sun.java2d.metal" are both set and are equal) {
>         // WARN and use the above default
>     } else if ("sun.java2d.opengl" is "true" || "sun.java2d.metal" is "false") {
>         pipelineOrder = { OPENGL, METAL };
>     } else if ("sun.java2d.opengl" is "false" || "sun.java2d.metal" is "true") {
>             pipelineOrder = { METAL, OPENGL };
>         }
>     }
> 
>     // Try the first pipeline in the list; if it fails, try the second
> 
> One advantage of the above is that it is trivial to change the default pipeline by just reversing the order in the initial list with no other changes needed.

> _Mailing list message from [Sergey Bylokhov](mailto:Sergey.Bylokhov at oracle.com) on [lanai-dev](mailto:lanai-
> How it will work if we will try to create a metal surface/device/etc when the metal is unsupported, I guess it just fail and we already should handle that?

Yes, we do handle conditions if metal device creation and metal shader library loading fails - but, I am not sure whether we get "symbol not found" error if we try to use JDK built on a system with metal framework and then download that bundle on a system where metal is not supported and test. Hence this additional check that uses system profiler command was introduced to detect Metal framework availability to bail out early if metal is not supported.
I have added a comment to JDK-8259825 to see whether we can get rid of this check altogether.

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

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