canvas and/or requestAnimationFrame stop working correctly after for an unknown amount of time
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
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
Comment 1•4 months ago
|
||
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.
Comment 2•4 months ago
|
||
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.
- Can you download the latest Nightly and check if this bug is fixed for you?
- Please type "about:support" in your Firefox browser and copy-paste its contents here.
- If this demo worked correctly for you in a previous version of Firefox, please use mozregression to do a bisection.
Reporter | ||
Comment 3•4 months ago
|
||
Reporter | ||
Comment 4•4 months ago
|
||
sorry sent early
- 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
Reporter | ||
Comment 5•4 months ago
|
||
(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.
- Can you download the latest Nightly and check if this bug is fixed for you?
- Please type "about:support" in your Firefox browser and copy-paste its contents here.
- 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.
Reporter | ||
Comment 6•4 months ago
|
||
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
Reporter | ||
Comment 7•4 months ago
|
||
after running a bisection for quite some time, this seems to be the last known good build
Comment 8•4 months ago
|
||
What is the first bad build? Was mozregression able to give the exact changeset that causes this issue?
Reporter | ||
Comment 9•4 months ago
|
||
(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?
Comment 10•4 months ago
|
||
This changeset corresponds to bug 1860048.
Reporter | ||
Comment 11•4 months ago
|
||
(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.
Comment 12•4 months ago
|
||
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.
Reporter | ||
Comment 13•4 months ago
|
||
(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!
Comment 14•4 months ago
•
|
||
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!
Reporter | ||
Comment 15•4 months ago
|
||
(In reply to Andrew Osmond [:aosmond] (he/him) from comment #14)
Can you confirm that going to
about:config
, flipping the prefwebgl.threadsafe-gl.force-disabled
totrue
, 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
Comment 16•4 months ago
|
||
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.
Reporter | ||
Comment 17•4 months ago
|
||
(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
Updated•3 months ago
|
Comment 18•3 months ago
|
||
The severity field is not set for this bug.
:lsalzman, could you have a look please?
For more information, please visit BugBot documentation.
Updated•3 months ago
|
Comment 19•3 months ago
|
||
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.)
Comment 20•3 months ago
|
||
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)
Reporter | ||
Comment 21•3 months ago
|
||
(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
Comment 22•3 months ago
|
||
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?
Comment 23•2 months ago
|
||
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.
Updated•2 months ago
|
Description
•