[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"
Perhaps we could come up with a definition based on "drastically slower than a native app making equivalent OpenGL calls", or perhaps to be less subjective, "requiring additional steps than a native app making equivalent OpenGL calls would demand"? In other words, if the browser is introducing additional steps to the render pipeline (e.g. readback for a "software compositor" as opposed to "direct rendering"), then fail to create the context. Perhaps the flag could be "failIfNotNative"? However software compositors like SwiftShader don't seem to fall under this definition. Perhaps then we could also fail to create if the first choice device is on the browser blacklist. For example, Chrome only uses Swiftshader if the system has a blacklisted device/driver, so Swiftshader can be clearly identified as a secondary or fallback renderer.
So, defining a "native context" as:
- comparable rendering pipeline to a native app
- first choice has not been blacklisted
Then if "failIfNotNative" is set to true, fail to create the context if:
- the browser will perform additional rendering steps that a native app would not typically perform, such as readback every frame
- the first choice renderer has been blacklisted
This is as objective a definition as I can come up with. I haven't defined all the terms I've used, but hopefully it still makes sense. It would also appear to solve the problem we face with our game engine. It would allow us to choose WebGL knowing it will be comparable to a GPU-accelerated native app, and fall back to canvas2d if not.
Alternatively, a simple and objective flag would be "failIfBlacklisted". This would indicate to fail to create a context if either the WebGL support or compositor/layers support for the primary device is subject to a blacklist. So this would imply both WebGL and composition are hardware accelerated.