<canvas> canvas animation is jerky on Firefox 3 beta 1, Linux x86_64

UNCONFIRMED
Unassigned

Status

()

Core
Canvas: 2D
P3
normal
UNCONFIRMED
10 years ago
8 years ago

People

(Reporter: Ilmari Heikkinen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b1) Gecko/2007113004 Minefield/3.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b1) Gecko/2007113004 Minefield/3.0b1

The Firefox 3 beta 1 on Linux x86_64 has frame duration spikes on canvas when filling large areas. The spikes happen roughly every 60 frames. 

If the canvas is in a tab that's not visible, the spikes disappear.

The frame duration spikes don't happen on Windows, nor on Firefox 2. 

Reproducible: Always

Steps to Reproduce:
1. create a canvas of 640x480
2. setInterval that clears the canvas and draws an animation (say, frame time histogram)

Actual Results:  
Every sixtieth frame or so takes a lot longer time than the median frame.

Expected Results:  
The frame rate stays stable.
(Reporter)

Comment 1

10 years ago
Created attachment 293140 [details]
Testcase that draws a frame duration histogram.
(Reporter)

Comment 2

10 years ago
Created attachment 293147 [details]
Screenshot of the above testcase on my computer.
(Reporter)

Updated

10 years ago
Summary: <canvas> frame duration spikes on Firefox 3 beta 1, Linux x86_64 → <canvas> canvas animation is jerky on Firefox 3 beta 1, Linux x86_64
(Reporter)

Comment 3

10 years ago
Happens on Firefox 3 beta 2 as well. And only when the canvas is visible.
You're most likely seeing the impact of garbage collection; in general, for animation, you don't want to use setInterval but want to use setTimeout and do your own timing (delta between last frame drawn and current for animation).
(Reporter)

Comment 5

10 years ago
Created attachment 293917 [details]
Testcase with hidden canvas vs. visible canvas

This being about GC is a bit suspect, since the problem only manifests on a visible canvas. The spikes also hang X (e.g. a video playing in mplayer stops on a spike), something that doesn't happen on GC spikes.
(Reporter)

Comment 6

10 years ago
Created attachment 293919 [details]
Screenshot of hidden vs. visible
If X is hanging during that timeframe, I suspect something in X (Render, say) is taking some time doing GC or other management of the video card.
Priority: -- → P3

Comment 8

9 years ago
I think it is the same bug, but for example this page http://blobsallad.se/ is particularly jerky with FF3 beta 5 (on Ubuntu 7.10 / amd athlon 64), although the same page is perfectly smooth with Opera or FF2 (on the same ubuntu computer), or even with FF3 beta 5 on win xp.
AFAIK, only the linux 64 version of FF3 seems to have the problem.
(Reporter)

Comment 9

9 years ago
This is probably related, I'm using the proprietary nvidia driver as well:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/238956
(Reporter)

Comment 10

9 years ago
A workaround is to set the driver attribute InitialPixmapPlacement=2

nvidia-settings -a InitialPixmapPlacement=2

Comment 11

9 years ago
Confirmed using x86 32-bit as well.

Comment 12

8 years ago
I was able to confirm the symptoms mentioned in Comment #1, using the supplied attachment-- I see spikes up to 1800ms.  I am running OpenSolaris 2008.11, with Xorg and the NVidia driver.

As per comment #10, applying the workaround with nvidia-settings smoothed out the performance considerably: no more spikes.
You need to log in before you can comment on or make changes to this bug.