Closed Bug 1529670 Opened 5 years ago Closed 3 years ago

Lag in background animation


(Core :: Graphics, defect, P3)

65 Branch





(Reporter: sspas4o, Assigned: rhunt)



(Keywords: perf)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I go here

Actual results:

I got a huge cpu usage and lag on the animated background.

Expected results:

I expect to work smooth like the dumbest IE. Here i made a video of the problem.

I could reproduce this issue on

User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

I do see high CPU usage on

Component: Untriaged → DOM: Animation
Ever confirmed: true
Product: Firefox → Core

There is a small animation here on the download button but the background is a <video> element with a blur filter applied to it (actually its parent <div>). On Linux at least, it's certainly smoother in Chrome than Firefox. Moving to Graphics.

Component: DOM: Animation → Graphics
Keywords: perf

The problem is indeed with the blur. Here's a profile [1]. There's some lock contention on the paint threads around a source surface. It's probably the video element.

Took a look at SkiaSourceSurface and I see we always lock around 'Map' and 'Unmap' even if all the users only want to read data from the source surface. This seems unnecessary, we should implement a multiple readers/single writer lock here.

I also tested this with webrender, and it's much better.


Depends on: fixed-by-webrender
Assignee: nobody → rhunt
Priority: -- → P3

So, using a RWLock in SourceSurfaceSkia eliminates this unnecessary contention. But this is only about 30ms out of about 230ms in this profile. Might be worth doing, but it's not a complete solution.

Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.