1881738 - "Terminate GPU process" on many canvas2d type demos completely freezes the browser for a long time (30s-1m) and then fallback to sw-wr

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Mayank Bansal]

1. Go to https://devnook.github.io/OffscreenCanvasDemo/use-with-lib.html
2. Open about:support in a new tab and drag it out to create a new Window.
3. Place the demo window and about:support side-by-side so tthat both are visible
4. In the about:support tab, click on "terminate the gpu process"

AR: The whole browser goes white and freezes.
ER: Not so?

Full disclosure that the STR are quite deliberate to stress-test firefox.

Regressed by:
Bug 1877010 - Track forwarder transaction ids for RemoteTextureMap with WebGL and WebGPU. r=sotaro
Differential Revision: https://phabricator.services.mozilla.com/D199876

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Attachment: log.txt-main.21392.moz_log

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

:lsalzman, since you are the author of the regressor, bug 1877010, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[Mayank Bansal]

Crash from using the firefox crash utility: https://crash-stats.mozilla.org/report/index/999a9d5b-7643-42f6-98fb-71c4c0240311#tab-details

Comment 6

[Mayank Bansal]

This still repros with the fix from bug 1887729

Comment 7

[Lee Salzman [:lsalzman]]

Attachment: Bug 1881738 - Don't send invalid remote texture owner id when WebGLChild is destroyed. r?aosmond

It seems like Canvas2D and WebGPU already avoid sending over invalid owner ids in GetFrontBuffer.
WebGL, however, can still blindly send an invalid texture owner id when the actor is being destroyed,
but the WebGL context is still alive.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9a2e1c938dee
Don't send invalid remote texture owner id when WebGLChild is destroyed. r=aosmond

Comment 9

[Lee Salzman [:lsalzman]]

Attachment: Bug 1881738 - Clean up ClientWebGLContext::GetFrontBuffer sync handling. r?aosmond

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/9a2e1c938dee

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a12f1f3ed2af
Clean up ClientWebGLContext::GetFrontBuffer sync handling. r=aosmond

Comment 12

[pstanciu]

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

Comment 13

[Mayank Bansal]

This is fixed for me on the latest Nightly.

Comment 14

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: 2024-05-09 09-42-49.mkv

Reproduced the issue using Firefox 125.0a1 (2024-02-23) on Windows 10x64. After clicking Terminate the GPU process on about:support page the browser goes white and freezes.
Firefox no longer freezes and the compositing remains to Webrender with Firefox 126.0a1(20240403093409) from comment 12 (Terminate GPU process is not available in 126.0 RC1) on Windows 10x64. However, sometimes the white window remains for some time, especially on the one with the test page loaded. Also, the test page does not fully reload (the canvas frames are empty) after the windows are painted. Is this expected? I have also attached a screen recording. Thank you!

Comment 15

[Lee Salzman [:lsalzman]]

If you tear down the GPU process, that it might take a few moments for the canvases to recognize that the GPU is gone and they need to restart.

Comment 16

[Alexandru Trif, Desktop Test Engineering [:atrif]]

(In reply to Lee Salzman [:lsalzman] from comment #15)

If you tear down the GPU process, that it might take a few moments for the canvases to recognize that the GPU is gone and they need to restart.

Thank you! Closing this as verified per comments 14 and 15.