egui fails to render in browser when using Backends::GL

[pierscowburn]

Description
I'm trying to get egui running in the browser using egui_wgpu_backend (rather than egui's own WebGL-based browser support).

I've been able to get it running using Backends::BROWSER_WEBGPU in Canary and also in Firefox Nightly, which is great. I'm now trying to also get it running using Backends::GL, as our project uses the GL backend as a fallback until browser support for WebGPU becomes mainstream.

Repro steps
https://github.com/pierscowburn/egui_wgpu_failure_case contains a minimal example. The example can be run with each backend as follows:

# Run with wgpu::Backends::BROWSER_WEBGPU
RUSTFLAGS=--cfg=web_sys_unstable_apis cargo run-wasm example

# Run with wgpu::Backends::GL
cargo run-wasm example --features webgl

Expected behavior
The example should render with a green background when using either backend.

Observed behavior
With the wgpu::Backends::BROWSER_WEBGPU backend the example renders correctly with a green background.

With the wgpu::Backends::GL backend the example renders with a red background (the clear color is set to red),
and some WebGL errors are printed to the console.

In Canary the warning is:

[.WebGL-0x7015b47700] GL_INVALID_OPERATION: It is undefined behaviour to use a uniform buffer that is too small.

In Firefox the warnings are:

WebGL warning: drawElementsInstanced: Buffer for uniform block is smaller than UNIFORM_BLOCK_DATA_SIZE.
WebGL warning: getSyncParameter: ClientWaitSync must return TIMEOUT_EXPIRED until control has returned to the user agent's main loop.

Platform

egui = "0.16"
egui_wgpu_backend = "0.16"
egui_winit_platform = "0.13"
wasm-bindgen = "0.2"
wasm-bindgen-futures = "0.4"
web-sys = { version = "0.3.56", features = [
    "console",
    "Document",
    "Element",
    "Performance",
    "Window",
]}
wgpu = "0.12.0"
winit = "0.26"

[svents]

I had the same issue a month ago. It is caused by the minimum buffer size in WebGL and can be solved in the egui_wgpu_backend by adding padding to a uniform buffer (they need to have a minimum size of 16).

I believe the "getSyncParameter" error message is independent of this problem. I have observed it as well in Firefox with egui rendering successfully.

[kvark]

Still a bug on our side. We shouldn't submit WebGL commands that are failing.

[emilk]

Side-note: wgpu support is being merged into the egui repository: emilk/egui#1564 (but untested on web).

[Mik-pe]

Stumbling upon similar issues as the "getSyncParameter" above, I can summarize some findings in regards to this:

There was another (erronous) printout in firefox ver <97, which was fixed through https://bugzilla.mozilla.org/show_bug.cgi?id=1733106

I believe the same example posted on bugzilla now (ver 101) produces another output, namely that TIMEOUT_EXPIRED is returned.

I do think that the code posted there should be valid, however, since all it does is ask if a fence has been signalled, so the warning printout seems to be overly verbose in this case.

webgl test code which should go through roughly the same firefox code paths:

var gl = document.createElement('canvas').getContext('webgl2');
gl.clearColor(0.2, 0.4, 0.6, 1);
gl.clear(gl.COLOR_BUFFER_BIT);
var pbo = gl.createBuffer();
gl.bindBuffer(gl.PIXEL_PACK_BUFFER, pbo);
gl.bufferData(gl.PIXEL_PACK_BUFFER, 4, gl.STREAM_READ);
gl.readPixels(0, 0, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, 0);
var sync = gl.fenceSync(gl.SYNC_GPU_COMMANDS_COMPLETE, 0);
var dstBuffer = new Uint8Array(4);

function checkResult() {
  var result = gl.clientWaitSync(sync, gl.SYNC_FLUSH_COMMANDS_BIT, gl.MAX_CLIENT_WAIT_TIMEOUT_WEBGL);
  switch (result) {
    case gl.TIMEOUT_EXPIRED:
      console.log("TIMEOUT_EXPIRED");
      window.requestAnimationFrame(checkResult);
      break;
    case gl.WAIT_FAILED:
      console.log("WAIT_FAILED  - gl.getError() = 0x" + gl.getError().toString(16));
      window.requestAnimationFrame(checkResult);
      break;
    case gl.ALREADY_SIGNALED:
      gl.getBufferSubData(gl.PIXEL_PACK_BUFFER, 0, dstBuffer, 0, 4);
      console.log("ALREADY_SIGNALED " + (dstBuffer[0] / 255) + " " + (dstBuffer[1] / 255) + " " + (dstBuffer[2] / 255) + " " + (dstBuffer[3] / 255));
      gl.deleteSync(sync);
      break;
    case gl.CONDITION_SATISFIED:
      gl.getBufferSubData(gl.PIXEL_PACK_BUFFER, 0, dstBuffer, 0, 4);
      console.log("CONDITION_SATISFIED " + (dstBuffer[0] / 255) + " " + (dstBuffer[1] / 255) + " " + (dstBuffer[2] / 255) + " " + (dstBuffer[3] / 255));
      gl.deleteSync(sync);
      break;
  }
}
checkResult();

[bluenote10]

What exactly is the status of these warnings?

WebGL warning: getSyncParameter: ClientWaitSync must return TIMEOUT_EXPIRED until control has returned to the user agent's main loop. (only warns once)

Were they independent of the core issue here? I'm wondering because #2802 apparently has resolved the aspect of "fails to render" but the warnings themselves still seem to occur.

In my case: I'm observing them in a relatively simple example, basically an attempt of turning the msaa-line example into a leptos app. I'm not really sure what to do now, since they seem to be triggered deep down by wgpu. Should I open a separate issue?

EDIT: Sorry, I missed this comment: #3064 (comment)

So does that mean they are entirely a false positive that should go away without any change?