Add support for some more WebGL2 limit parameters

[mmatyas]

Adds support for the following new WebGL2 GetParameter values:

• MAX_ELEMENT_INDEX
• MAX_ELEMENTS_INDICES
• MAX_ELEMENTS_VERTICES
• MAX_FRAGMENT_INPUT_COMPONENTS
• MAX_SAMPLES
• MAX_SERVER_WAIT_TIMEOUT
• MAX_TEXTURE_LOD_BIAS
• MAX_VARYING_COMPONENTS
• MAX_VERTEX_OUTPUT_COMPONENTS

See: https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.7.2

cc @jdm @zakorgy

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• There are tests for these changes

[highfive]

Heads up! This PR modifies the following files:

• @asajeffrey: components/script/dom/webgl2renderingcontext.rs
• @KiChjang: components/script/dom/webgl2renderingcontext.rs

[highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[jdm]

@bors-servo r+
Thanks!

[bors-servo]

📌 Commit 9799870 has been approved by jdm

[bors-servo]

⌛ Testing commit 9799870 with merge 62c10d6...

[bors-servo]

💔 Test failed - status-taskcluster

[jdm]

  ▶ CRASH [expected OK] /_webgl/conformance2/uniforms/query-uniform-blocks-after-shader-detach.html
  │ 
  │ _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
  │ called `Option::unwrap()` on a `None` value (thread WebGL thread, at components/canvas/webgl_limits.rs:236)
  │ stack backtrace:
  │    0: <servo::backtrace::Print as core::fmt::Debug>::fmt
  │    1: core::fmt::write
  │    2: std::io::Write::write_fmt
  │    3: servo::backtrace::print
  │    4: servo::main::{{closure}}
  │    5: std::panicking::rust_panic_with_hook
  │    6: rust_begin_unwind
  │    7: core::panicking::panic_fmt
  │    8: core::panicking::panic
  │    9: <canvas_traits::webgl::GLLimits as canvas::webgl_limits::GLLimitsDetect>::detect
  │   10: canvas::webgl_thread::WebGLThread::handle_msg
  │   11: canvas::webgl_thread::WebGLThread::process
  │   12: std::sys_common::backtrace::__rust_begin_short_backtrace
  │   13: core::ops::function::FnOnce::call_once{{vtable.shim}}
  │   14: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  │   15: std::sys::unix::thread::Thread::new::thread_start
  │   16: _pthread_body
  │   17: _pthread_start

I think we need to use try_get_float instead of get_float for some of the new limits.

[mmatyas]

Hm, yet another graphics issue I can't seem to reproduce... According to the spec, the only float value is MAX_TEXTURE_LOD_BIAS, the rest of them are integers. The only difference I see that might count is that MAX_ELEMENT_INDEX is a GLint64, so probably we should use glGetInteger64v. However, we already have 64bit values queried with get_integer (eg. MAX_UNIFORM_BLOCK_SIZE), so if that would be the problem, then the tests should have failed already too.

I'll see if I can add the 64bit integer method to sparkle, we can then try it out if that's indeed the issue here.

[jdm]

I checked on my mac, and it's panicking on max_element_index = gl.get_integer(gl::MAX_ELEMENT_INDEX);.

[mmatyas]

Thanks for checking! I've updated the call for MAX_ELEMENT_INDEX and, just in case, the rest of the 64bit values too.

PS. I'm not sure about returning it as UInt32 to the JS side though, should it be eg. DoubleValue instead?

[jdm]

Yes, DoubleValue would be safer.

[mmatyas]

Ok, updated to use DoubleValues. I've also changed the CLIENT/SERVER_WAIT_TIMEOUTs to it too.

[jdm]

@bors-servo r+
Thanks!

[bors-servo]

📌 Commit 68ad98c has been approved by jdm

[bors-servo]

⌛ Testing commit 68ad98c with merge a4e636e...

[bors-servo]

💔 Test failed - status-taskcluster

[jdm]

Curious; we're still panicking when calling max_element_index = gl.get_integer64(gl::MAX_ELEMENT_INDEX);.

[jdm]

I suspect the issue is GL_MAX_ELEMENT_INDEX is accepted by pname only if the GL version is 4.3 or greater. from https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGet.xhtml. https://searchfox.org/mozilla-central/source/dom/canvas/WebGL2ContextState.cpp#102-106 from Firefox has special handling for this attribute. We only request GL 3.2 in WebGLVersion::to_surfman_version for WebGL2.

[mmatyas]

Hm, if I remember correctly we only have extension querying at the moment; can/should we make the same isSupported route to the GL layer and back? Or perhaps we should just return some max value for now? Maybe keep the field as an Option when the GlLimits is created?

[jdm]

I suggest using try_get_integer64 and unwrap_or(0).

[mmatyas]

Ok, updated.

[jdm]

@bors-servo r+

[bors-servo]

📌 Commit e0c4d49 has been approved by jdm

[bors-servo]

⌛ Testing commit e0c4d49 with merge 84e2252...

[bors-servo]

💔 Test failed - status-taskcluster

[jdm]

Fixed the remaining panic in #26354.