Re: [fxtf-drafts] [filter-effects-2] Backdrop filters should not use BackgroundImage

The CSS Working Group just discussed `Backdrop filters should not use BackgroundImage`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Backdrop filters should not use BackgroundImage<br>
&lt;dael> github: https://github.com/w3c/fxtf-drafts/issues/53<br>
&lt;dael> chrishtr: We talked at TPAC. Advantages of perf and impl simplicity raised<br>
&lt;dael> chrishtr: Also good b/c consistant with things like mized blend mode. Obj was mixed blend mode doesn't respect isolation. Turns out that was typo in example<br>
&lt;dael> chrishtr: Reasons we should have BackdropFilter in the isolated group are performance, ease of impl, consistancy with other modes<br>
&lt;dael> chrishtr: Since TPAC Mason Freed (?) has done research in HTTP Archive and we couldn't find any site that had an effect not easily achievable by parenting BackgroundFilter under root stacking context<br>
&lt;dael> smfr: I think when Mixed Blend MOde was impl I thought it was a mistake. Point of backdrop filters you blur everything behind your element. Trivial to create test cases where you couldn't get the desired effect. Happens to be used like fixed position because it's less intence. The effect designers haven't tried they can't get. We need to give deisgners wide scope rather then force to fudge with page<br>
&lt;dael> TabAtkins: Agree it's trivial to create test cases, we haven't found any realistic cases where we can't achieve without moving element within the DOM. It's not just a matter of free choice. Lots of more difficult technicla issue if allowed inside various filters and stacking context.<br>
&lt;dael> TabAtkins: If entire content is blurred, in a blur filter container and blur backdropfilter does it have 1 or 2 blurs?<br>
&lt;dael> TabAtkins: Hard quesiton tot answer if you can do arbitrary blending with whatever is behind you. If it's stacking context based it's much simplier<br>
&lt;dael> smfr: Agree there are issues to be resolved if element with backgroundfilter has other effects.<br>
&lt;dael> smfr: If there aren't anything behind the elemtns that's no ambig on order. Impl is similar in 2 cases except one you have to get the bitmap to apply to and the other you render from stacking context<br>
&lt;dael> smfr: It's hard and expensive which we knoew, but you get a nice graphic property. I think it supplies more use case.<br>
&lt;dael> smfr: It would be hard for webkit to impl any other way because we rely on system set backdrop<br>
&lt;dael> TabAtkins: We've got the opposite problem<br>
&lt;dael> TabAtkins: You glossed over difficulty of resolvign double filter. Example: container with blur. 2 pieces of content, an element and a backdrop blur that's on top of first<br>
&lt;dael> TabAtkins: Blur on container is understood, but does that mean backdrop filter does a blur of what's behind me sees a blurred child and does a blur or does it see the unblurred child? There isn't a simple answer and your decision will have strict implications on how to impl. Following strict stacking gives you a clear answer<br>
&lt;dael> TabAtkins: Even if you say we do it b/c how platform does, I don't know how your platform would handle this case.<br>
&lt;dael> TabAtkins: I'm concerned about this as generally all pixels underneath. That's hard to define<br>
&lt;dael> smfr: Easy to define of appendix of CSS2.2 You render everything up to the element with backdropfilter. It's different the mixed blend mode and different to SVG filters. I think in blurring we should clarify with test cases.<br>
&lt;dael> smfr: If saying element behind has blur you blur and then apply backgroundfilter<br>
&lt;dael> TabAtkins: Container has the blur. That's unclear if before or after<br>
&lt;dael> smfr: I think you blur the thing with backdrop additionally<br>
&lt;dael> TabAtkins: Blur entire contents then do backgroudfilter blur?<br>
&lt;dael> smfr: If blur is on a container of the backdrop...[thinks]<br>
&lt;dael> chrishtr: Have to drop content underneath, apply blur, backdrop filter, draw under, and blur it all again.<br>
&lt;dael> chrishtr: It can be done, but it's quite strange. Also a big perf cliff. Drawing everything a second time and applying effects doubles the display list. Also what if there's a scroller or a video back there. Or multiple nested backdropfilters. Run time will be exponential<br>
&lt;dbaron> I think in some cases (e.g., backgrdrop filter inside something with opacity) the right thing to do "visually" may be to *invert* the opacity (which can be seen as one case of a filter)<br>
&lt;dbaron> but not all filters are invertible<br>
&lt;dael> astearns: Given that you have said the use case for not isolating can be achieved by changing where things are in DOM, that perf cliff is around anyway as far as I understand. it just depends on arranging<br>
&lt;dael> TabAtkins: Under our pref wouldn't work if you nest weird or it's up high in the hierarchy and the effect works fine. So it's cheap or works differently in a visible way. Either way it's cheap-ish<br>
&lt;dael> chrishtr: Also if you define to isolated group you don't get expoential with backdropfilter. Each is a stacking context so only goes up to containing thing.<br>
&lt;dael> chrishtr: General concern about introducing something with large, poss exponential, to the platform without a known effect that justified<br>
&lt;dael> smfr: Would like to do this on a call with dino. Can we bring this to next APAC call?<br>
&lt;dael> astearns: Also useful to continue adding cases to this issue. We can do this async and provide better clarity.<br>
&lt;dael> TabAtkins: Do both.<br>
&lt;dael> chrishtr: smfr could you reach out to dino?<br>
&lt;dael> smfr: Yep.<br>
&lt;dael> astearns: That's prob enough on this issue.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-438747705 using your GitHub account

Received on Wednesday, 14 November 2018 17:28:45 UTC