WebGL in content process always used SharedSurface_SurfaceTexture until Bug 1632249 fix. Since the fix, SharedSurface_SurfaceTexture is not used if webgl.enable-surface-texture is false.

The following is old implementation for selecting SurfaceFactory_SurfaceTexture.
https://searchfox.org/mozilla-esr68/source/gfx/gl/GLScreenBuffer.cpp#94

Since Bug 1632249, at first, TexTypeForWebgl() chooses TextureType::AndroidNativeWindow only when StaticPrefs::webgl_enable_surface_texture() is true.

• https://searchfox.org/mozilla-central/rev/3b6958c26049c1e27b2790a43154caaba9f6dd4a/gfx/layers/CanvasRenderer.cpp#121

Then SurfaceFactory::Create() chooses a factory when texture type is TextureType::AndroidNativeWindow.

• https://searchfox.org/mozilla-central/rev/3b6958c26049c1e27b2790a43154caaba9f6dd4a/gfx/gl/SharedSurface.cpp#121

: jgilbert, can you take this bug?

It sounds like the pref is set wrong, but we had two wrongs make a right before, when we ignored the pref!

This should match the previous behavior where non-parent processes
ignored the pref and used surface textures.

Set release status flags based on info from the regressing bug 1632249

Jamie, enabling SurfaceTexture-backed WebGL as this patch attempts to do seems to MOZ_CRASH for me in Fenix[1]. I get some relevant looking driver spew before:

07-22 16:15:06.251 26521 26542 I Adreno  : GetNumBufferSupported: clamped value 2 is not suitable as it exceeded maxBufferCount requested by consumer 1
07-22 16:15:06.251 26521 26542 I Adreno  : InitializeInternal:GetNumBufferSupported failed
07-22 16:15:06.251 26521 26542 I Adreno  : Create: Initialize failed
07-22 16:15:06.251 26521 26542 I Adreno  : GetNumBufferSupported: clamped value 2 is not suitable as it exceeded maxBufferCount requested by consumer 1
07-22 16:15:06.251 26521 26542 I Adreno  : InitializeInternal:GetNumBufferSupported failed
07-22 16:15:06.251 26521 26542 I Adreno  : Create: Initialize failed

Do you have a chance to look into this? Without the ST path, WebGL is doing readpixels under WebRender and it's very sad.

[1] https://crash-stats.mozilla.org/report/index/31b3f3d5-98cf-4181-8c61-227a90200722

Hey snorp, I've tried to reproduce your crash but it works fine for me on a few different devices. Webgl aquarium runs poorly, then I flip that pref and it runs much faster, without crashing.

Is there a specific website you encountered this on? Is it reproducible? Could you try a different device and see if that makes a difference?

(In reply to Jamie Nicol [:jnicol] from comment #8)

Hey snorp, I've tried to reproduce your crash but it works fine for me on a few different devices. Webgl aquarium runs poorly, then I flip that pref and it runs much faster, without crashing.

Is there a specific website you encountered this on? Is it reproducible? Could you try a different device and see if that makes a difference?

It's every website (that uses WebGL), but I've only tried it on Pixel 4 XL. I'm charging some other devices to try there.

P1 bug sitting around for a while without a fix. Jeff can we get something moving here or update the status flags? Thanks!

No problem on Pixel 2, so seems to be somewhat specific to my Pixel 4 XL.

Interesting. Thanks for testing!

Sotaro, do you have a Pixel 4 or Pixel 4XL? Kris, this is an important crash to fix. If Sotaro doesn't have a device maybe I should order one for myself?

In the meantime should we enable the pref but add some code to disable it on the Pixel 4 XL? (and maybe the Pixel 4, and maybe all Adreno 640 devices)

The problem seems related to using a single-buffer SurfaceTexture. If I use a multi-buffer one it doesn't crash, but perf is awful (about 4 fps). Profile shows fDrawElements() taking forever, which is very curious.

We probably need to adjust the EGLConfig somehow to be compatible with a single-buffer SurfaceTexture.

Maybe Sotaro's AHardwareBuffer work might fix it, too.

I think there are some API levels on which we're forced to use multi-buffer, so we should make sure performance isn't terrible on those!

(In reply to Jamie Nicol [:jnicol] from comment #12)

Interesting. Thanks for testing!

Sotaro, do you have a Pixel 4 or Pixel 4XL?

Sorry, I do not have them, I just have Pixel 3a and it did not cause the problem.

Since Adreno 640 will be enabled on next release with FF80 and it looks like we don't have a solution for this in mind yet, disabling WR for 640 and uplifting sounds like the right choice.

To move this forward, is there anything we can try without buying the phone?

This pref isn't currently enabled, so I don't think we have to worry about uplifting anything just yet. We should enable it though (with a workaround of some sort for affected devices).

I'm also not sure whether it's webrender specific? Presumably we're currently going through a readback path for layers too, and flipping this pref will make both layers and webrender use SurfaceTextures? It might be a useful clue if it does in fact only crash for webrender.

Snorp, does it only crash with webrender enabled? Or does it crash for either layers or webrender? Also, has canvas always crashed on your Pixel 4XL when using the SurfaceTexture path, or is it a recent regression (likely from the OOP changes)?

(In reply to Jamie Nicol [:jnicol] from comment #17)

Snorp, does it only crash with webrender enabled? Or does it crash for either layers or webrender?

It crashes the same way with or without WR.

Also, has canvas always crashed on your Pixel 4XL when using the SurfaceTexture path, or is it a recent regression (likely from the OOP changes)?

I'm not totally sure. I can try to bisect a bit.

mozregression isn't working, but I can't seem to repro the crash anymore with latest m-c. It also works in Fenix nightly. I'd say we should go ahead and land this.

Backed out changeset 25f0521ab3a1 (Bug 1654459) for causing reftest crash in webgl-color-test.html CLOSED TREE

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedTaskRun=F5O2uinETryaoTPHqt7G5Q.0&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=android%2C7.0%2Cx86-64%2Cdebug%2Creftests%2Ctest-android-em-7.0-x86_64%2Fdebug-geckoview-reftest-e10s%2Cr1&revision=25f0521ab3a1d879d630cf2fbefee643729e7cf5

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313355272&repo=autoland&lineNumber=28782

Backout: https://hg.mozilla.org/integration/autoland/rev/297140bda15a1014c1af4515738b20c991b949b6

Also crashes: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313382822&repo=autoland&lineNumber=2306

(In reply to Natalia Csoregi [:nataliaCs] from comment #22)

Also crashes: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313382822&repo=autoland&lineNumber=2306

This looks similar to Bug 1659681.

https://hg.mozilla.org/mozilla-central/rev/d32596b492b1

Backed out changeset 1c35c35dd964 (Bug 1654459) for causing reftest failures in webgl-color-test.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/ae2a56ca44dc538b7d3a3ade4722d00174b23a2f

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&fromchange=d299116b9e8487c35e9aef28e58774b799f1f8ae&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Copt%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fopt-geckoview-reftest-e10s%2Cr1&tochange=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=SYicNa4UQTWrRb5JLNjQiw.0

https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Cdebug%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fdebug-geckoview-reftest-e10s%2Cr1&revision=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=WOzW0OOORdeiwgnncSDglQ.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314758596&repo=autoland&lineNumber=27412

(In reply to Alexandru Michis [:malexandru] from comment #28)

Backed out changeset 1c35c35dd964 (Bug 1654459) for causing reftest failures in webgl-color-test.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/ae2a56ca44dc538b7d3a3ade4722d00174b23a2f

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&fromchange=d299116b9e8487c35e9aef28e58774b799f1f8ae&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Copt%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fopt-geckoview-reftest-e10s%2Cr1&tochange=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=SYicNa4UQTWrRb5JLNjQiw.0

https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Cdebug%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fdebug-geckoview-reftest-e10s%2Cr1&revision=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=WOzW0OOORdeiwgnncSDglQ.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314758596&repo=autoland&lineNumber=27412

I wonder if the problem might be related to Bug 1595026.

(In reply to Sotaro Ikeda [:sotaro] from comment #29)

I wonder if the problem might be related to Bug 1595026.

Yeah, that seems plausible. Also, all of the failures have "readback" in the query string, which seems significant. I would've guessed that would cause it to use the readback path and avoid SurfaceTexture entirely, but maybe that's not right? Jeff?

I confirmed that WebGL with SurfaceTexture and WebRender worked on Android8 emulator(x86) and Android 10 emulator(x86) . It did not work on Android 7 emulator(x86) . Android 7.0 emulator is current default emulator on m-c. WebGL became stable with Bug 1665300.

(In reply to Sotaro Ikeda [:sotaro] from comment #29)

(In reply to Alexandru Michis [:malexandru] from comment #28)

Backed out changeset 1c35c35dd964 (Bug 1654459) for causing reftest failures in webgl-color-test.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/ae2a56ca44dc538b7d3a3ade4722d00174b23a2f

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&fromchange=d299116b9e8487c35e9aef28e58774b799f1f8ae&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Copt%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fopt-geckoview-reftest-e10s%2Cr1&tochange=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=SYicNa4UQTWrRb5JLNjQiw.0

https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Cdebug%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fdebug-geckoview-reftest-e10s%2Cr1&revision=284e3c053bf57ee8f331b21a90751936ee604482&selectedTaskRun=WOzW0OOORdeiwgnncSDglQ.0

I saw a similar rendering artifact with Android 7.1.1 emulator with GPU on Windows. The rendering happened correctly with Android 8.0 emulator with GPU on Windows.

When I run SurfaceTexture WebGL on Android 7.1.1 device with Adreno 506, the problem did not happen. WebGL was rendered as expected. Then the problem seemed to happen only on Android 7 emulator.

https://hg.mozilla.org/mozilla-central/rev/19541d7e6dab

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #30)

(In reply to Sotaro Ikeda [:sotaro] from comment #29)

I wonder if the problem might be related to Bug 1595026.

Yeah, that seems plausible. Also, all of the failures have "readback" in the query string, which seems significant. I would've guessed that would cause it to use the readback path and avoid SurfaceTexture entirely, but maybe that's not right? Jeff?

It might not be working properly. :S Thanks for the heads-up.