CSS blur filter seriously impacts performance in Chrome

[marcoambrosini]

Notice the sharp fps drop when the filter is active

Screen.Recording.2022-09-12.at.14.26.21.mov

[nickvergessen]

Cc @jancborchardt @nimishavijay we might have to drop the filter/transparency for the call view. Dropping FPS by 75% does not sound acceptable.

[marcoambrosini]

The same problem happens with the navigation. I think we should blur the image on the server and send it to the client, along with the regular one.

[danxuliu]

Despite the initial fears, after a lot of testing this may not be exactly the same issue that we had in the past with the blur filter for the background of call participants, although it is difficult to say :-( Back in the day it was easily reproducible in Chromium (and Safari, which ultimately led to completely disabling the blur, as the work around developed for Chromium could not be used in Safari), but fortunately this one seems much more restricted. That could be just a side effect of GPU rasterization now being enabled by default on GNU/Linux, but the filter type probably plays a role too.

The video above was captured in a virtual machine where Chromium graphics features were either disabled or software only (as shown in chrome://gpu). However, when running Chromium in the host with GPU rasterization, compositing and OpenGL having blur or not does not feel different. If GPU rasterization is disabled (which can be done in chrome://flags) again there is no difference between having blur or not; there is no lag in either case.

But there is also an interesting difference between the old blur and the current one: the old blur was used in a filter CSS property, while the current one is used in a backdrop-filter CSS property. The following examples (rename to .html rather than .txt) show the difference between them (the blur value is extremely large to emphasise the performance hit):
test-blur.txt
test-blur-backdrop.txt

Chromium does not render again the DOM elements unless something changes. This can be checked in the frame rendering stats (Developer tools->Customize and control DevTools->More tools->Rendering) after opening the samples; if nothing changes in the page the stats are not updated. However, when hovering on the text its background is coloured, which causes a redraw and the stats are updated.

In the virtual machine both filter types cause lag; it happens even when updating an element that is not overlapping the element that has the blur (for example, the first paragraph in the backdrop-filter example). But on the host, on an older system from almost 20 years ago, and on a relatively recent laptop from 4 years ago, all without GPU rasterization, updating the text background when hovering it has lag if filter is used, but it does not if backdrop-filter is used. This can be checked by quickly moving the cursor over the text, entering an exiting it; this shows a much lower FPS when using filter than when using backdrop-filter. And if filter is disabled the FPS increase when doing it again.

It is also worth noting that testing an actual call with the backdrop-filter blur in the old system does not feel more laggy than without blur (it is far from snappy, but it does not feel worse, as it is the case in the virtual machine).

To sum up, from my tests:

• With GPU rasterization there is no noticeable performance hit
• Without GPU rasterization:
  • There is no noticeable performance hit when running Chromium in a real machine, even an old one, and using backdrop-filter (which is the property used now) rather than filter (the one that caused issues in the past)
  • There is a noticeable performance hit when running Chromium in a virtual machine, even if backdrop-filter is used (as shown in the video); it could be related to other hardware accelerated features not being available besides the GPU rasterization

However, there are also issues in Chromium bug tracker about blur being slow with GPU rasterization rather than without it 🤷 (although I can not reproduce that). So it would be good to have more testing on this (with actual calls rather than the test code), preferably with low end devices, as the sample size right now is quite limited.

[Antreesy]

Window size	3840 x 2160 pixels (4K)	1920 x 1080 pixels (Full HD)
Blur enabled
Blur disabled
Difference	🔽 62% less GPU load	🔽 63% less GPU load

As it was also reported by customers, may we consider for the moment it solves to make a blurring optional?

We could introduce a new section in Talk settings and store a value in BrowserStorage, but let it survive log-out, as it's more a device setup rather than a user preference for all devices:

[jancborchardt]

What about the middle ground / first step of removing the blur for the grey call background?
Since the left navigation is blurred globally in Nextcloud, we should tackle that separately.

[joebnb]

still a problem