925025 - CSS blur filter is order of magnitude slower than Chrome

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Chad Austin]

Our new product, withme.com, can have a layer of WebGL underneath, with a CSS blur mask applied on top, with WebGL on top of that.  In this scenario, Firefox 24 on my Ivy Bridge 3770K w/ HD Graphics 4000 is probably 4-6 times slower than Chrome on the same machine.  The frame rate in Firefox feels like it's about 3 or 4, where Chrome is easily usable at about 15 or more.

To reproduce:

1) open https://withme.com/game/slots/
2) click Play.
3) multiple WebGL avatars should appear
4) click the shirt icon in the upper left

Expected: reasonable frame rate
Actual: horribly slow frame rate

Comment 1

[Alon Zakai (:azakai)]

How are you measuring frame rate? In firefox, I clicked and dragged on the avatar after pressing the shirt, to try to notice refresh speed - it looked pretty snappy. This is on linux with intel graphics.

Comment 2

[Chad Austin]

I'm measuring with my eyeballs and I've only tested on this one machine...  though other people here say it happens with non-Intel GPUs on Windows 7.

Comment 3

[Chad Austin]

Tested on my 2010 MacBook Pro.

2.53 GHz Intel Core i5
NVIDIA GeForce GT 330M 256 MB

The frame rate is 2x or 3x faster in Chrome when the blurred mask UI is shown.

Comment 4

[u279076]

Seems like this is not specific to Windows 8.1 based on comments.

Comment 5

[Ray Shan]

Can confirm this is not specific to Windows. It seems to happen when a large, blurred element is also transformed. Here's another test case since original comments' link is no longer valid.

Macbook Air mid-2013 with i7 1.7 GHz and Intel HD Graphics 5000. Yosemite 10.10.4

Tested with Firefox 40, Chrome 44 and Safari 8.

Open http://codepen.io/codebrendon/pen/bdQmLe, hover button.

Firefox gets about 1/2 the frame rate vs. Chrome and Safari.

Comment 6

[wimer]

Can confirm. Happens when CSS blur filter is used together with CSS transform. It also happens to me with a blur filter on an element with its children having a CSS transform transition.

Comment 7

[u459114]

all urls are broken.

Comment 8

[Christian Sonne [:cers]]

Attachment: configurable test case

I came across this issue trying to blur a canvas that was animating. I've attached a simple test where you can easily benchmark the performance with and without blur - the expected time is pretty close to 10000 ms.

I've also included the results from testing it in different browsers on my mid 2012 macbook pro with various canvas sizes.

The scaling constant S determines the size of the image in pixels via the formula (30 * S) x (20 * S).

+------------+-----------+--------------+
| S = 8      | Blur (ms) | No blur (ms) |
+------------+-----------+--------------+
| Chrome 61  |     10096 |        10029 |
| Firefox 56 |     10082 |        10031 |
+------------+-----------+--------------+
| S = 25     | Blur (ms) | No blur (ms) |
+------------+-----------+--------------+
| Chrome 61  |     10096 |        10029 |
| Safari 11  |     10046 |        10054 |
| Servo git  |     11740 |        11481 |
| Firefox 56 |     37706 |        10036 |
| Firefox 58 |     37722 |        10035 |
+------------+-----------+--------------+
| S = 35     | Blur (ms) | No blur (ms) |
+------------+-----------+--------------+
| Chrome 61  |     10036 |        10035 |
| Firefox 56 |     64722 |        10040 |
+------------+-----------+--------------+

The largest canvas Firefox could blur without incurring a time penalty was 240 x 160 (S = 8), and the largest one Chrome could blur was 1050 x 700 (S = 35). Using this metric, Chrome's blur filter is a bit more than 19 times faster than ours.

Comment 9

[evv.info]

Attachment: [Codepen] blur-scale CSS transition demo

Comment 10

[jalminde]

Also seeing a big slowdown in Firefox vs. Chrome and Safari when enabling the blur filter on an element containing a WebGL canvas. I have only eyeballed it, but it’s very noticeable.

Does anybody have an idea of what is causing this issue?

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Safari and Chrome both do blur on the GPU Firefox does it in software unless WebRender is turned on. You could try turning on the gfx.webrender.all pref and that should improve things.

Comment 12

[steve]

I've just noticed this same issue while testing a CSS transition on an image header:

.header-image {
  transition: all 0.5s ease-in-out;
}

.zoomed header-image {
  opacity:   0.3;
  filter:    blur(10px);
  transform: scale(1.5, 1.5);
}

When adding the 'zoomed' class to the parent element, the problem is evident and seems consistent with previous reports that it is a combination of blur and transform. I appreciate that this is a fairly hefty amount of styling to apply in one hit, but Chrome and Safari are very smooth while Firefox is coming to a shuddering halt when running it.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

(In reply to steve from comment #12)
> I've just noticed this same issue while testing a CSS transition on an image
> header:

You can try out WebRender in Firefox Nightly by setting the gfx.webrender.all pref. I'd encourage you to do so and report back with the results. It should be improved.

Comment 14

[steve]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #13)
> (In reply to steve from comment #12)
> > I've just noticed this same issue while testing a CSS transition on an image
> > header:
> 
> You can try out WebRender in Firefox Nightly by setting the
> gfx.webrender.all pref. I'd encourage you to do so and report back with the
> results. It should be improved.

Thanks Jeff. I will certainly do that but this is a problem I hit while developing for a production website, so obviously I can't adopt that as a public solution. I assume I can just ignore the blur with a vendor prefix in the short term to get around this?

Comment 15

[Jeff Muizelaar [:jrmuizel]]

(In reply to steve from comment #14)
> Thanks Jeff. I will certainly do that but this is a problem I hit while
> developing for a production website, so obviously I can't adopt that as a
> public solution. I assume I can just ignore the blur with a vendor prefix in
> the short term to get around this?

Yes, unfortunately that's probably the best option for now.

Comment 16

[steve]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)
> (In reply to steve from comment #14)
> > Thanks Jeff. I will certainly do that but this is a problem I hit while
> > developing for a production website, so obviously I can't adopt that as a
> > public solution. I assume I can just ignore the blur with a vendor prefix in
> > the short term to get around this?
> 
> Yes, unfortunately that's probably the best option for now.

Actually that isn't possible. There is no vendor prefixed version of the filter property.

"-moz-filter" is showing as an invalid property name.

If I try to limit the blur effect statement to -webkit-filter: blur(10px) Firefox still picks it up.

Some other more convoluted workaround needed, unfortunately.

Comment 17

[David]

I opened another issue before I found this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1532300
Did anyone manage to find some workaround? Firefox picks up the -webkit-filter property. I was trying to avoid ugly css hacks on production.

Comment 18

[David]

I guess this is the only workaround for now:

   filter: none !important;
  }```

Comment 19

[Jürg Lehni]

I noticed this problem too at the end of last year. Just tested the same code again on Firefox 87.0 and it is now as fast as Chrome, if not faster!

It sure looks like this is address finally! 🥳

Comment 20

[Navid Vahdat]

Clearly not solved in my case!

I'm using 3 feGaussianBlur Filters for a shadow on a SVG element, that is dragged with a mouse. Chromium based Edge is perfectly smooth. Firefox very jerky.

With Edge I see rather high GPU load and a little extra CPU load while dragging.
With Firefox there is a little higher GPU load and lot of extra CPU load while dragging.

Firefox 100.2 (64-bit) on Windows 10

Comment 21

[nonetrix]

I don't know if this is related but backdrop blur is terribly slow compared to Chrome when enabled in about:config

It's perfectly fine on my desktop which I think is more due to my hardware being able to power through it, but on my phone it's terribly slow compared to Chromium based browsers on the same phone

Misskey.io is a website that uses it heavily and is very noticeable

My phone is a Google Pixel 3A which is on the lower end but also not a slouch

Comment 22

[Jeff Muizelaar [:jrmuizel]]

This bug has a bunch of different reports all lumped in together. The original problem was fixed by WebRender. If you're still experiencing problems with blur please open a new bug and you can post the number here.