Should we limit the list of supported texture formats?
cabanier opened this issue · comments
Implementing the list of supported formats is showing a large amount of texture color and depth formats.
Is it really necessary to surface them all and allow them in the API?
My worry is that this might create content that only works on certain devices (ie Quest supports a format and Hololens doesn't) and that this might leak information.
/agenda discuss if we should limit the list of supported texture formats
Can't join for today's call, though I am interested in the outcome here. HoloLens 2 does have particular formats that are more efficient given our hardware reprojection/scanout pipeline, and so we do want to encourage use of those formats if possible. However, I agree that this creates both a compat and a privacy risk.
HoloLens 2 also has a particular technical nuance there where using BGRA rather than RGBA doesn't actually pay off performance-wise until the app also avoids y-flip, which may be a harder ask for WebGL apps, and so just encouraging use of BGRA may not be worth those tradeoffs you mentioned for us on its own.
We discussed this in the call today and we decided the following:
- remove the methods that returns the list of supported color and depth textures
- add a minimum list of supported formats that every UA should support to the spec
- add logic so if compressed texture support is turned on in the context, they are allowed as a format for every layer except projection layers.
HoloLens 2 also has a particular technical nuance there where using BGRA rather than RGBA doesn't actually pay off performance-wise until the app also avoids y-flip, which may be a harder ask for WebGL apps, and so just encouraging use of BGRA may not be worth those tradeoffs you mentioned for us on its own.
@thetuvix Does webgl2 support BGRA?