1434978 - css blur is slow on EventBrite

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[Greg Tatum [:gregtatum]]

There is a noticeable very bad lag on Eventbrite with a page with a very large box blur filter.

STR:
 * Goto: https://www.eventbrite.com/e/eyeo-festival-2018-tickets-42647939134
 * Tab back and forth between another tab and this tab.
 * There is an obvious slow lag when switching.

ER:
 * Fast tab switching and displaying the page like in other browsers.

AR:
 * The time is spent re-rendering: img.listing-hero-image which has the following filter: `filter: blur(50px) brightness(0.9)`
 * The content main thread is waiting on paint: https://perfht.ml/2BLk004
 * The PaintWorker is chewing on `mozilla::gfx::AlphaBoxBlur::BoxBlur_SSE2` applying the filter: https://perfht.ml/2BLh2Zq

Comment 1

[Greg Tatum [:gregtatum]]

Oh, and this was on my 2015 MacBook Pro (retina display). Reproduced in Firefox 59 and 60, the profile was recorded on 60.

Comment 2

[Kelsey Gilbert [:jgilbert]]

BoxBlur -> :bas?

Comment 3

[Bas Schouten (:bas.schouten)]

Yup, that's pretty bad! Not sure why this is taking so much time on this page, probably some layout thing blurring way too large a surface. I don't think our box blur code can be obviously sped up (the code itself was pretty fast when I last checked), so the solution here would have to be doing less blurring. Fwiw it performs fine with D2D on my machine, but that might because D2D is accelerating it.

Comment 4

[Kelsey Gilbert [:jgilbert]]

Cool, sounds worth looking into.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Greg Tatum [:gregtatum] [@gregtatum] from comment #0)
>  * The PaintWorker is chewing on `mozilla::gfx::AlphaBoxBlur::BoxBlur_SSE2`
> applying the filter: https://perfht.ml/2BLh2Zq

Based on this ^^ and similarity to bug 1474985 (in that function & blur perf issues), I'm assuming this is fixed by webrender; hence, tying to bug 1475349.

Comment 6

[Markus Stange [:mstange]]

(In reply to Bas Schouten (:bas.schouten) from comment #3)
> I don't
> think our box blur code can be obviously sped up (the code itself was pretty
> fast when I last checked), so the solution here would have to be doing less
> blurring.

We could also apply some techniques that compromise on the blur quality, e.g. blurring at a lower resolution. It looks like Skia's blurring code already does it, albeit maybe only on the GPU path: https://github.com/servo/webrender/issues/1894#issuecomment-337769810