Closed Bug 1924400 Opened 4 months ago Closed 2 months ago

canvas and/or requestAnimationFrame stop working correctly after for an unknown amount of time

Categories

(Core :: Graphics: Canvas2D, defect)

Firefox 131
Desktop
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1924578

People

(Reporter: lixam.vincent, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

leaving any page with a canvas using requestAnimationFrame to animate something ends up doing a weird stutter locked between 2 frames after some time

I have searched many hours what could be the cause of this, but nothing seems to cause it on its own, it just happens at some point

I've had this bug occur on my current machine, for at least the past month, and also on a machine running Ubuntu (I'm not sure of the Ubuntu version, and don't currently have access to this machine)

I've tried it on google chrome, no issues, tried in a private Firefox window with all extensions disabled, still an issue

Actual results:

any animation ends up in one of 3 states:
-locked on a frame
-alternating between 2 frames that seem to be one after another

  • alternating between 1 fixed frame and the animation continuing as normal (most frequent of what I've tried)

I've checked the timestamp in the requestAnimationFrame callback, and even when the bug occurs, the timestamp runs as expected

Expected results:

the animation should continue and not lock up like shown in the video

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Canvas2D' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Graphics: Canvas2D
Product: Firefox → Core

Thanks for reporting the bug. This looks similar to bug 1922278 which has been fixed on Nightly.

I cannot reproduce this bug on my Win11x64 machine.

  1. Can you download the latest Nightly and check if this bug is fixed for you?
  2. Please type "about:support" in your Firefox browser and copy-paste its contents here.
  3. If this demo worked correctly for you in a previous version of Firefox, please use mozregression to do a bisection.
Flags: needinfo?(lixam.vincent)
See Also: → 1922278
Attached file logs
(In reply to Mayank Bansal from comment #2) > Thanks for reporting the bug. This looks similar to bug 1922278 which has been fixed on Nightly. > > I cannot reproduce this bug on my Win11x64 machine. > > 1. Can you download the latest Nightly and check if this bug is fixed for you? > 2. Please type "about:support" in your Firefox browser and copy-paste its contents here. > 3. If this demo worked correctly for you in a previous version of Firefox, please use [mozregression ](https://mozilla.github.io/mozregression/)to do a bisection. 1. Just did that, will let it run for a bit before reporting 2. Here is the full data:

sorry sent early

  1. the bug has been occuring for quite some time now, i'll try with mozregression, but since each version test takes up to 30 minutes, it'll be some time before I get results
Flags: needinfo?(lixam.vincent)

(In reply to Mayank Bansal from comment #2)

Thanks for reporting the bug. This looks similar to bug 1922278 which has been fixed on Nightly.

I cannot reproduce this bug on my Win11x64 machine.

  1. Can you download the latest Nightly and check if this bug is fixed for you?
  2. Please type "about:support" in your Firefox browser and copy-paste its contents here.
  3. If this demo worked correctly for you in a previous version of Firefox, please use mozregression to do a bisection.

after leaving the page run on firefox nightly, the bug still occurs as described before, I haven't had time to try with mozregression for now.

Doing some more testing with nightly and mozreggression, the bug seems to occur only when the tab goes into the background
looking at a few forums on the subject, it seems that requestAnimationFrame pauses when in the background, so maybe a misstimed callback from requestAnimationFrame? I'll check again with google chrome to make sure my first tests were valid

What is the first bad build? Was mozregression able to give the exact changeset that causes this issue?

(In reply to Mayank Bansal from comment #8)

What is the first bad build? Was mozregression able to give the exact changeset that causes this issue?

sorry did not see the email notification after leaving

this is the first bad changeset: 559980ba7004936b535f16967ffbe30944d7f04a (https://hg.mozilla.org/integration/autoland/rev/559980ba7004936b535f16967ffbe30944d7f04a), I saved this but I don't have the exact build, I shut down my computer, does mozregression save that kind of data?

This changeset corresponds to bug 1860048.

Flags: needinfo?(aosmond)
Keywords: regression
Regressed by: 1860048

(In reply to Mayank Bansal from comment #10)

This changeset corresponds to bug 1860048.

now knowing this, what should I do? the bug is marked as fixed, but the bug still occurs on firefox and firefox nightly.

I have marked dependency on that bug,and the developer has been copied.
The dev will look at this bug as per their prioritization.
Nothing for you to do right now.

(In reply to Mayank Bansal from comment #12)

I have marked dependency on that bug,and the developer has been copied.
The dev will look at this bug as per their prioritization.
Nothing for you to do right now.

okay, thank you for your help!

Can you confirm that going to about:config, flipping the pref webgl.threadsafe-gl.force-disabled to true, and restarting solves the problem? In a recent build, ideally nightly. Thanks!

Flags: needinfo?(aosmond) → needinfo?(lixam.vincent)

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

Can you confirm that going to about:config, flipping the pref webgl.threadsafe-gl.force-disabled to true, and restarting solves the problem? In a recent build, ideally nightly. Thanks!

on firefox-nightly up to date, after setting webgl.threadsafe-gl.force-disabled to true, the bug still occurs
what is strange is that I have the option showing up twice when looking in about:config

unless there is a confirm button in about:config, the bug is still an issue even with this option disabled

Flags: needinfo?(lixam.vincent)

Very strange. I suppose it must be DMABUF? Can you do the same thing, but also flip widget.dmabuf.enabled to false, restart and test? Thanks.

Flags: needinfo?(lixam.vincent)

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

Very strange. I suppose it must be DMABUF? Can you do the same thing, but also flip widget.dmabuf.enabled to false, restart and test? Thanks.

yep, DMABUF seems to be the culprit
disabling DMABUF the bug dissapeared ( ~6h test, no bug), to be sure it wasn't some confirmation thing with config, trying to reenable it the bug came back

Flags: needinfo?(lixam.vincent)
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(lsalzman)
See Also: 19222781907828

Since this bug is still UNCONFIRMED, feel free to contact one of my addon users which seems to experience this random issue:
https://github.com/WesselKroos/youtube-ambilight/issues/270

(My addon uses requestAnimationFrame to draw video frames onto a canvas.)

Hi!
I'm the guy who reported https://github.com/WesselKroos/youtube-ambilight/issues/270 and I seem to be affected by the bug reported here.

Just to confirm it, I tried the mentioned workaround on the versions listed below:
widget.dmabuf.enabled set to "false"
and
webgl.threadsafe-gl.force-disabled set to "true"

on 132.0 the bug still happens
on 134.0a1 (2024-11-05) Nightly the bug hasn't happened so far (tested for ~ 1 day)

Specs:
CPU: i7 13700k
GPU: RTX 3090ti + 565.57.01 driver
Up to date CachyOS(Arch Linux)

(In reply to Jonathan from comment #20)

Hi!
I'm the guy who reported https://github.com/WesselKroos/youtube-ambilight/issues/270 and I seem to be affected by the bug reported here.

Just to confirm it, I tried the mentioned workaround on the versions listed below:
widget.dmabuf.enabled set to "false"
and
webgl.threadsafe-gl.force-disabled set to "true"

on 132.0 the bug still happens
on 134.0a1 (2024-11-05) Nightly the bug hasn't happened so far (tested for ~ 1 day)

Specs:
CPU: i7 13700k
GPU: RTX 3090ti + 565.57.01 driver
Up to date CachyOS(Arch Linux)

I've also got a Nvidia GPU, a 2080 Super, same drivers.
I've also tried alternatives to requestAnimationFrame, like setInterval, the issue is still present,
I don't have an Amd GPU but it would probably be a good idea to check if the issue is specific to nvidia cards

I tried again on versions Nightly 134.0a1 (2024-11-05) as well as 134.0a1 (2024-11-07)
but this time I reverted the workaround, so the following settings were active:

  • widget.dmabuf.enabled set to "true"
  • webgl.threadsafe-gl.force-disabled set to "false"

and I haven't experienced the bug again so far. I guess the issue is already fixed on nightly and will come with the next firefox release(s) ?
Maybe someone else can verify?

Just FYI:
I have been daily driving the beta release for about two weeks now (when it was still version 133) and I have not experienced the issue again - I just updated firefox to 134.0b1 today and still no issues.
The two settings from my comment directly above are still active.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Duplicate of bug: 1924578
Flags: needinfo?(lsalzman)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: