Open markschlosseratbentley opened 1 year ago
What would remain if you removed all of the WebGL-1-specific stuff? Bear in mind the compatibility checker is going to need to continue to be able to report compatibility for 3.x too.
What would remain if you removed all of the WebGL-1-specific stuff? Bear in mind the compatibility checker is going to need to continue to be able to report compatibility for 3.x too.
In the totally-public-facing WebGLFeature enum, there are some items that look like they would get reported still -- float rendering, antialiasing stuff, shadow maps. But a lot will go away.
We also use Capabilities
for other things in the system, though, like checking if we can render to floats, which is what started me down the path of thinking about more broadly removing WebGL1 from this part of the code - since WebGL2 no longer requires WebGL1's quirky ways of checking that.
Two possibilities I see for the compatibility checker itself:
1) I mainly envisioned that the compatibility checker will use a 3.x version of iTwin.js to report compatibility for 3.x apps. A small change could be backported to the 3.x release of webgl-compatibility so it can know whether or not 4.x will be supported. Then the compatibility checker can be upgraded to use 4.x versions of the compatibility libraries once 3.x support is eventually dropped.
2) Otherwise, if we want the checker to be on the very latest iTwin.js (4.x) and be able to report both situations (3.x and 4.x), then we will need to disentangle some of this code. Some code that the internal system checks in Capabilities.ts needs to get updated properly to take into consideration that WebGL1 is gone, while it also can report stuff about WebGL1 still for the purposes of the compatibility checker letting people know about 3.x compatibility.
I am not sure which is better, but I feel option 1 would result in clearer code in 4.x -- allowing us to drop WebGL1 concepts everywhere. Suggestions welcome.
I see this is "in progress" - what is its urgency relative to other priorities?
IModelApp.queryRenderCompatibility
to report "incompatible" if WebGL 2 is not supported; if WebGL 2 is supported, none of the WebGL-1-specific limitations will be reported as missing.Is Safari still stupid about floating point textures with a WebGL 2 context?
This mainly stems from https://github.com/iTwin/itwinjs-core/issues/5018 which work began on investigating - you're right, lower priority. Moving back to TODO. There are a lot of moving pieces here.
Safari still does have some issues on certain iOS devices with full floating point, that is true, at least last I checked.
Related to this work item: https://github.com/iTwin/itwinjs-core/issues/5018
Related to this PR: https://github.com/iTwin/itwinjs-core/pull/4999
That PR didn't modify the webgl-compatibility APIs, but we need to. Looking at the isTextureRenderable() path, we might as well remove the rest of the WebGL1-only stuff while we are at it.