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

Ajit Ghaisas aghaisas at openjdk.java.net
Mon Jan 11 11:57:17 UTC 2021


On Mon, 11 Jan 2021 09:54:51 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> this implies that -Dsun.java2d.opengl=false on its own means the same as -Dsun.java2d.metal=true.
>> 
>> This is a bit grayer. It would imply that there is a designated fall back.
>> 
>> I take that back - it isn't grey. Because the default for metal is false, it means you've disabled both so rule 1 applies
>> I'll add another rule up above to make it clearer.
>> 
>> But .. we have a sort of precedent on windows that d3d=false means fall back to gdi. So that contradicts the above :-(
>> 
>> So is metal a "fallback" or an "option" ? We don't fall back to optional pipelines. Meaning d3d=false would not cause opengl to be used on windows.
>
>> this implies that -Dsun.java2d.opengl=false on its own means the same as -Dsun.java2d.metal=true.
>> 
>> This is a bit grayer. It would imply that there is a designated fall back.
>> 
>> I take that back - it isn't grey. Because the default for metal is false, it means you've disabled both so rule 1 applies
>> I'll add another rule up above to make it clearer.
>> 
>> But .. we have a sort of precedent on windows that d3d=false means fall back to gdi. So that contradicts the above :-(
>> 
>> So is metal a "fallback" or an "option" ? We don't fall back to optional pipelines. Meaning d3d=false would not cause opengl to be used on windows.
> 
> My thinking differs on this. When we will integrate Lanai JEP to the mainline, we will have 2 rendering pipelines on macOS - OpenGL and Metal - OpenGL being default.
> If user specifically asks for -Dsun.java2d.opengl=false, then we should definitely try to use the other available pipeline - whether it is fallback or optional is immaterial. Otherwise, we would end up in a situation where no UI will be launched.
> 
> I suggest that we deliberate and decide on this outside of this PR.

> _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.

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

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


More information about the lanai-dev mailing list