1529670 - Lag in background animation

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[sspas4o]

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 https://signup.eune.leagueoflegends.com/en/signup/redownload?page_referrer=index

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.

Comment 1

[sspas4o]

https://www.youtube.com/watch?v=n_r32q78IS0 Here i made a video of the problem.

Comment 2

[Kanchan Kumari QA]

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 https://signup.eune.leagueoflegends.com/en/signup/redownload?page_referrer=index

Comment 3

[Brian Birtles (:birtles, Feb 26~ parental leave)]

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.

Comment 4

[Ryan Hunt [:rhunt] (on leave until early May)]

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.

[1] https://profiler.firefox.com/public/403fedfca054ba215d1005745cbc0f930b90143f/calltree/?globalTrackOrder=11-0-1-2-3-4-5-6-7-8-9-10&hiddenGlobalTracks=1-2-3-4-5-6-7-8-9&hiddenLocalTracksByPid=78099-0-1-2~78528-0-1-2-3~78098-0-1-2-3~79901-0-1-2-3&range=10.5887_12.3770~11.2872_11.5312&thread=29&v=3
[2] https://searchfox.org/mozilla-central/rev/00f3836a87b844b5e4bc82f698c559b9966e4be2/gfx/2d/SourceSurfaceSkia.cpp#145

Comment 5

[Ryan Hunt [:rhunt] (on leave until early May)]

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.