1696967 - Web games are slow since v86, solved by disabling gfx.canvas.remote

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P1)

Description

[Asif Youssuff]

From: https://www.reddit.com/r/firefox/comments/luh0qi/web_games_are_very_slow_since_v86/

User says that games like https://www.freecivweb.org/webclient/?action=new&type=singleplayer on a APU AMD 7600 had slowed down since the upgrade to v86.

Setting "gfx.canvas.remote"=false seems to resolve their issue.

There seems to be some additional observations here - https://www.reddit.com/r/firefox/comments/lqimww/firefox_860_see_all_new_features_updates_and_fixes/gogpnke/ regarding https://www.vsynctester.com/

i have intel potato with 2500 graphic, and by default the https://www.vsynctester.com/ test was red and cyan.

setting it to false give me better fps + smooth grey.

Comment 1

[Bob Owen (:bobowen)]

Thanks for reporting this.
Asif - it would be good if we could get a profile from the original reporter, to see if they are hitting the same issue as me below.

I've dug out a 7 or 8 year old laptop and tried a couple of these games.
I didn't see much of an issue with the links in the description (or at least no difference with remote canvas disabled), but in diep.io I do see some issues.
Profiling that it looks like in my case it is down to taking the snapshot ready for copying to the next frame, before unlocking/returning the previous texture client. This means an extra copy is taking place in the SourceSurfaceD2D1 on DetachAllSnapshots and we are not saving a copy later on, because that snapshot's bitmap is copied into the next frame and then discarded. The destruction of those textures is also taking a fair amount of time.

This snapshot before return was originally put in, because I appeared to be getting contention reading from the texture in the content process for the next frame and reading in the compositor thread in the GPU process. The lock on the textures cannot distinguish between reading and writing.
I think we should be able to avoid these extra copies and textures by instead immediately after returning the texture, selecting the next texture and copying directy into that. This will require a read lock, but hopefully doing it upfront will avoid the contention and the compositor would have to be waiting for the creation and copy before the unlock currently anyway.

Comment 2

[Bob Owen (:bobowen)]

Attachment: Bug 1696967: Only snapshot before unlocking canvas texture when caching a data surface. r=jrmuizel!

Doing this every frame causes issues for older GPUs with the extra bitmap
creation, copy and destruction. Instead the TextureRecorded now only takes a
snapshot when it is going to cache a data surface to improve getting data back
at the start of a frame.

Comment 3

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/jobs?repo=try&revision=b4baa14a8cd44227b1b27e23d64d74255b059a33

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0f292e686866
Only snapshot before unlocking canvas texture when caching a data surface. r=jrmuizel

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/0f292e686866

Comment 6

[Asif Youssuff]

Bob, sorry about the delay - got a new profile for freecivweb.org/webclient - https://share.firefox.dev/3cEw2Nj

Here's hoping it is the same issue you discovered!

Comment 7

[Bob Owen (:bobowen)]

(In reply to Asif Youssuff from comment #6)

Bob, sorry about the delay - got a new profile for freecivweb.org/webclient - https://share.firefox.dev/3cEw2Nj

Here's hoping it is the same issue you discovered!

Thanks, I'm fairly hopeful that the change that has landed will help all round, but there could be other specific issues.
It would be useful if anyone is willing to retest with the latest Nightly with remote canvas enabled.
If they still have a problem another profile with the "Firefox Graphics" settings would be great (they now capture the CanvasWorkers threads on Nightly as well).

I'll try and profile that game on an old laptop before and after the fix as well, to see if I can see anything.

Comment 8

[Bob Owen (:bobowen)]

(In reply to Asif Youssuff from comment #6)

Bob, sorry about the delay - got a new profile for freecivweb.org/webclient - https://share.firefox.dev/3cEw2Nj

Here's hoping it is the same issue you discovered!

On my old laptop, I see a pretty similar profile in Release for that game, but it is much improved for me in the latest Nightly.
Hopefully the original reporter will see an improvement as well.
The fix is in the latest Beta as well now.

Comment 9

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue with low frames on Firefox Nightly (2021-03-08) under Windows 10 by using the links provided in Comment 0.

The issues are fixed on Firefox Nightly 89.0a1 (2021-04-05) and Firefox 88.0b7 under Windows 10. Gpu used - Intel HD mobile 4000.