Web-Facing Change PSA: Update CSS backdrop-filter to use mirror edgeMode

[Robert Flack]

Contact emails

fla...@chromium.org, michae...@google.com

Specification

https://drafts.fxtf.org/filter-effects-2/#backdrop-filter-operation

Summary

The backdrop-filter CSS property applies one or more filters to the "backdrop" of an element. The "backdrop" basically means all of the painted content that lies behind the element. A common filter is a blur allowing designers to construct "frosted glass" dialog boxes, video overlays, translucent navigation headers, and more. This was initially implemented the same way as a regular blur, but sampling beyond the edges of the element allowed colors from the edges to bleed in. The spec was changed to sample pixels outside the backdrop edges by duplicating the pixels at the edge. This however, results in extreme flickering of content as it enters the backdrop edge. The latest spec change mirrors the backdrop when sampling beyond the edge which allows for a smooth gradual introduction of new colors at the edges without overweighting on single lines of color.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The specific visual result of a blur backdrop-filter is currently quite different between Chrome, Firefox and Safari, as such this developers could not rely on any interoperable behavior today. This change visually aligns closely to Safari's filter - if not identical, so should bring those two in rough alignment. We agreed upon this new behavior in the CSSWG resolutions for the new edgeMode[1] and using this edgeMode for backdrop-filter[2]. [1] https://github.com/w3c/fxtf-drafts/issues/527 [2] https://github.com/w3c/fxtf-drafts/issues/374

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1051)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/372) This change is visually very similar to the blur being applied in Safari which doesn't have the flickering issues that our current duplicate edgeMode has.

Web developers: No signals There have been many negative signals about the current duplicate behavior that this change resolves (all duplicated into the main bug): https://issues.chromium.org/issues/40040614 There is positive sentiment for Safari's behavior on https://issues.chromium.org/issues/40666159 and https://issues.chromium.org/issues/40040614 which this change in behavior aligns with.

Other signals:

Ergonomics

There are no known ergonomic risks.

Activation

This should be an improvement to the quality of blur backdrop-filters that developers are already using and further allow developers to adopt them without worrying about the flickering edge cases of the duplicate filter. Developers don't need to do anything other than use the backdrop-filter property.

Security

There are no known security risks. This is replacing one sampling algorithm with another.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

As a change to the visual blur, there is no specific debugging support.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/filter-effects?label=master&label=experimental&aligned&q=%2Fcss%2Ffilter-effects%2Fbackdrop-filter-

Flag name on chrome://flags

chrome://flags/#backdrop-filter-mirror-edge

Finch feature name

BackdropFilterMirrorEdgeMode

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/u/1/issues/40040614

Estimated milestones

Shipping on desktop	129
DevTrial on desktop	127
Shipping on Android	129
DevTrial on Android	127
Shipping on WebView	129

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5382638738341888?gate=6076747077648384

This intent message was generated by Chrome Platform Status.

[Daniel Clark]

Is there a specific set of tests under https://wpt.fyi/results/css/filter-effects?label=master&label=experimental&aligned&q=%2Fcss%2Ffilter-effects%2Fbackdrop-filter- that highlight this behavior change? I would have expected, for example, some set of tests to recently start passing in Chrome due to this change, which would already have been passing in Safari and fail in Firefox. But there a number of other differences in tests like backdrop-filter-edge-*.html causing failures such it’s hard to tell what the real status is.

 

Or are there just too many other browser differences with backdrop-filter to make this kind of comparison realistic?

 

-- Dan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TOb6j0EbXZG%3DJ96GZ27jYfu-k_J9cjA0Osi_aTKgoe9yQ%40mail.gmail.com.

[Robert Flack]

WPT will start passing the following tests when the flag is enabled:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/TestExpectations?q=file:TestExpectations%20virtual%5C%2Fbackdrop-filter-mirror-edge

wpt.fyi does not show this because the feature is controlled by a flag outside of blink and so couldn't be associated with --experimental-web-platform-features which wpt.fyi uses.

[PhistucK]

Given that this is a visual change and all of the text here is not really showing it, a before/after video would help understand and visualise the change, would you share some? :)

☆PhistucK

--

[Robert Flack]

There are two good static examples in WPT

I'll include screenshots of the first (which you can see by comparing chrome's result) here:

https://wpt.fyi/results/css/filter-effects/backdrop-filter-boundary.html?label=experimental&label=master&aligned

Before this change, as you increase the blur radius you sample more and more of the edge pixels losing all of the colors of the interior. This is because any sampling beyond the edge simply duplicates the edge color.

Afterwards with this change, you can see that as the blur radius increases you get an average of all of the pixel colors instead. This is done by mirroring the sampling beyond the edge back into the backdrop.

A similar issue can be seen on https://wpt.fyi/results/css/filter-effects/backdrop-filter-edge-mirror.html?label=experimental&label=master&aligned where a box with a single pixel blue border has a backdrop blur filter applied.

Setting static examples aside, because of the extreme overweighting of the edge pixels, if you have a moving pane with a backdrop blur filter over content, when the edge crosses over a new color it can cause extreme flicker, which you can see on the demo linked from the intent, but as requested I can attach movies here if i can keep them small enough.

Before: backdrop-blur-edge-duplicate.mov

After: backdrop-blur-edge-mirror.mov

In the before you can see extreme flickering which was "correct" by the previous spec text which said that you duplicate the color at the edge when sampling beyond it. In the after video mirroring sampling beyond the edge the introduction of the red line at the edge is much more subtle. There are several linked bugs showing real world examples of flickering related to the duplicate edge mode.

Admittedly there is still some slight flickering in the after video, however I believe this may be that we're not updating the rendering quickly / smoothly enough rather than an issue of the mirror strategy.

[Yoav Weiss (@Shopify)]

Is there something developers would need to do differently after this change? Or is this an improvement that they won't have to worry about?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPup1iaML8Z2Yy%3DYdR_xDy7Mtm1VknZr9GUYJ9mjZYSFQ%40mail.gmail.com.

[Robert Flack]

Apologies if I didn't cover this well enough in the activation section, there are no API changes at all. This is strictly a visual quality improvement to the way backdrop-filter samples pixels beyond the edges (primarily for blurs) that more accurately weights the content is it blurring producing less flicker and an overall more representative blur. 

[Yoav Weiss (@Shopify)]

Thanks for clarifying! :)

[PhistucK]

Thank you for sharing the videos! They help a lot.

> which you can see on the demo linked from the intent

I did, but since I only have the current version of the effect, I only have the before. :)

> Admittedly there is still some slight flickering in the after video

Indeed... Is this going to be tackled?

☆PhistucK