1871744 - Intermittently blink of <canvas> with remote canvas on windows

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Toshihiro Yamada]

Attachment: about-support.txt

Happens with 12/23 nightly on Win11/x64 (Attach about:support)

STR:

1. Set gfx.canvas.remote to true (it is default)
2. Open https://developer.mozilla.org/ja/docs/Web/API/Canvas_API/Tutorial/Basic_animations
3. Show canvas element.

Expected result:
The canvas element animates normally.

Actual result:
The canvas element blinks intermittently.

Works normally when gfx.canvas.remote is false.
So, regression from Bug 1871467?

Comment 1

[Timothy Nikkel (:tnikkel)]

I'll set regressed by field tentatively for now.

Comment 2

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

:lsalzman, since you are the author of the regressor, bug 1871467, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Lee Salzman [:lsalzman]]

Sotaro, are you able to reproduce this? Is this a potential bug in RemoteTextureMap? Could this be related to a failure to allocate a D3D11TextureData, due to too many being processed, or something like that?

Comment 4

[Sotaro Ikeda [:sotaro]]

I could reproduce the problem on my Win10 PC with the STR. The problem could be easily reproducible when there was other window that run https://webglsamples.org/aquarium/aquarium.html.

I wonder if the following might be related.

• https://searchfox.org/mozilla-central/rev/a9cb718ef1502bc0fe5088476748e334fad9d6a1/gfx/layers/ipc/CanvasTranslator.cpp#50

ALLOC_MANUAL_SYNCHRONIZATION could be used only when ID3D11Texture2D is allocated by compositor device. But canvas device is not compositor device.

https://searchfox.org/mozilla-central/rev/a9cb718ef1502bc0fe5088476748e334fad9d6a1/gfx/thebes/DeviceManagerDx.cpp#383

Comment 5

[Sotaro Ikeda [:sotaro]]

For now, it seems better to remove ALLOC_MANUAL_SYNCHRONIZATION to address the regression.

Comment 6

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro PTO Dec/28 -Jan/4] from comment #5)

For now, it seems better to remove ALLOC_MANUAL_SYNCHRONIZATION to address the regression.

But when ALLOC_MANUAL_SYNCHRONIZATION flag was removed, canvas was not rendered :( Going to look into it. I wonder if Bug 1870950 might be related to it.

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro PTO Dec/28 -Jan/4] from comment #6)

(In reply to Sotaro Ikeda [:sotaro PTO Dec/28 -Jan/4] from comment #5)

For now, it seems better to remove ALLOC_MANUAL_SYNCHRONIZATION to address the regression.

But when ALLOC_MANUAL_SYNCHRONIZATION flag was removed, canvas was not rendered :( Going to look into it. I wonder if Bug 1870950 might be related to it.

With latest m-c the above problem did not happen. Bug 1871811 might address the problem.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1871744 - Remove ALLOC_MANUAL_SYNCHRONIZATION in CanvasTranslator::CreateTextureData()

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

Out of curiosity, does setting gfx.canvas.remote.worker-threads to 0 and restarting help? That makes canvas always run on CanvasRenderer thread instead of the CanvasWorkers thread pool. Both should guarantee only one thread ever accesses the texture at a time, but setting the pref to zero ensures it is always the same thread.

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

From https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nn-dxgi-idxgikeyedmutex:
Represents a keyed mutex, which allows exclusive access to a shared resource that is used by multiple devices.

It isn't used on multiple devices. Is there something going wrong with the copy we make?

Comment 11

[Sotaro Ikeda [:sotaro]]

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)

Out of curiosity, does setting gfx.canvas.remote.worker-threads to 0 and restarting help?

It did not help for me.

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #10)

It isn't used on multiple devices. Is there something going wrong with the copy we make?

The ID3D11Texture2D is used both with canvas device and compositor device.

Comment 13

[Sotaro Ikeda [:sotaro]]

D197276 addressed the problem for me.

Comment 14

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

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

Comment 15

[Lee Salzman [:lsalzman]]

Attachment: Bug 1871744 - Use FIFO queue for recycling textures instead of stack. r?sotaro

Moving to a FIFO queue means that textures that were just pushed into the recycling
queue will be reused last, reducing the amount of possible lock contention.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c765c015a552
Remove ALLOC_MANUAL_SYNCHRONIZATION in CanvasTranslator::CreateTextureData() r=gfx-reviewers,lsalzman

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/484bd1eca3b5
Use FIFO queue for recycling textures instead of stack. r=sotaro,gfx-reviewers

Comment 19

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c765c015a552
https://hg.mozilla.org/mozilla-central/rev/484bd1eca3b5

Comment 20

[Toshihiro Yamada]

Confirmed fixed on latest nightly(12-26).
Thanks!!

Comment 22

[Intermittent Failures Robot]

6 failures in 1162 pushes (0.005 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 3
• mozilla-central: 2
• try: 1

Platform and build breakdown:

• windows11-32-2009-qr: 3
  • opt: 2
  • debug: 1
• windows11-64-2009-qr: 3
  • debug: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1871744&startday=2023-12-25&endday=2023-12-31&tree=all