WebGL Conformity

[jlpoolen]

Testing for WebGL Conformity

Background

Wikipedia tells us about WebGL:

WebGL (short for Web Graphics Library) is a JavaScript API for rendering interactive 2D and 3D graphics within any compatible web browser without the use of plug-ins.[

There is a web page that can undertake testing of your browser's implemenetation of WebGL at: https://registry.khronos.org/webgl/sdk/tests/webgl-conformance-tests.html

I saw that the number of tests were immense, so I asked ChatGPT "how long should it take to run the GL conformance tests?" and it advises:

In practical terms, if you are running a comprehensive test suite on a standard setup without parallelization, it can take several hours. For more targeted or optimized configurations, the time can be considerably reduced. [Boldface added.]

My experience

I commenced testing with several of my environments, i.e. Gentoo Linux and Debian Linux and Firefox and Chromium thereon, and found 1) my Gentoo laptop w/32 GB RAM crashed and was turned off in the morning, 2) Firefox crashed with no error report in both Debian and Gentoo VMs, and 3) Chromium in a well endowed Gentoo Linux VM (64 MB RAM, 32 available processors through Xen's shared processors) completed with a report showing several fails. The lack of 100% PASS for three different environments has me wondering 1) about testing using the above URL, 2) about the implementation of MapLibre's GL, and 3) if there is any documentation or matrix on what features of WebGL MapLibre Gl implements. So I thought I'd start this discussion with the hope of comments from senior developers on this project sharing their perspective.

What brought me to look into this area is the fact that I have maps in two different open source project which display using the MapLibre-gl-Inspect (http://unpkg.com/maplibre-gl@latest/dist/maplibre-gl-inspect.js), but not the "latest" version (https://unpkg.com/maplibre-gl@latest/dist/maplibre-gl.js). I am wondering if this discrepancy is a result of my hardware and/or LInux environment.

[HarelM]

I'm not sure what is the expected outcome from this discussion, but we don't have any matrices of which version of OS and browser work. Generally speaking, latest and greatest should work for latest version.
If someone is using maplibre and has statistics of things working or not working it is usually these companies/projects who has the ability to test what can fix incompatibility issues and open a PR to solve this issues.
We did try and migrate to webgl 2 but it caused too much noise when we did that.
A general "it crashes" statement isn't very helpful to understand what caused an issue and it's very hard to comment about it.

This is my personal point of view.

[jlpoolen]

I'm not sure what is the expected outcome from this discussion, but we don't have any matrices of which version of OS and browser work. Generally speaking, latest and greatest should work for latest version. If someone is using maplibre and has statistics of things working or not working it is usually these companies/projects who has the ability to test what can fix incompatibility issues and open a PR to solve this issues. We did try and migrate to webgl 2 but it caused too much noise when we did that. A general "it crashes" statement isn't very helpful to understand what caused an issue and it's very hard to comment about it.

This is my personal point of view.

So the standard the MapLibre-gl-js project conforms to is Web Gl 1.0 (https://registry.khronos.org/webgl/specs/latest/1.0/). In which case, I should be testing against Web Gl 1.0 and not 2.x. That's helpful to know. My test against 2.0 had about a 93% PASS rate and I made the leap of faith that MapLibre-gl-js was conforming to Web Gl 2.x, so your response is helpful in defining the standard. I'm interpreting your phrase "too much noise" to mean there were too many incompatibilities and/or failures to conform to the 2.x standard.

One thing I have learned is that for Debian, installed on a VM, the google-chrome browser in a default setting does not support WebGL. It looks like testing presentations within web browsers on VMs could be prone to problems unless the browser have some support or additional features activated.

[HarelM]

Maplibre tried to use webgl 2, and if this is not supported it falls back webgl 1.
We tried removing the webgl 1 code, and that created incompatibility.