W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > November 2018

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

From: Mason Freed via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Nov 2018 00:45:24 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-442275033-1543365923-sysbot+gh@w3.org>
@mstange, we were discussing your [comment above](https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-438431485) concerning opacity. There are several examples where it would make sense for the filtered backdrop to form the starting point for the backdrop-filtered element, so that opacity (and other filters) would apply to that filtered content. One example would be a dialog box that “fades out”. Given that this change should not cause any performance issues, I’ve modified our proposed definition for backdrop-filter. I also included more detail about transforms applied to the backdrop-filtered element, to clarify those as well. Your feedback is appreciated:

1. Draw the ancestor stacking context (call it A), in paint order, up to the backdrop-filtered element (call it B). Assume the buffer being drawn to this point is called A’.
2. Copy everything painted so far into a temporary buffer (call it T’), and apply the backdrop-filter’s filter operations to that temporary buffer.
3. If element B has any transforms, apply the **inverse** of those transforms to the contents of T’.
4. Apply a clip to the contents of T’, using the border box of element B. Note that the children of B are not considered for this clip.
5. Draw all of element B and the children of B into T’.
6. If element B has any transforms, effects, or clips, apply those to T’.
7. Composite the contents of T’ into A’, using source-over compositing.
8. Continue drawing the remainder of the children of A.

Again, we believe that having backdrop-filter only apply up to the parent stacking context makes sense for these reasons:
1. It is the only definition that can be unambiguous for the case of nested elements with filters and opacity applied. If we simply define it to filter “everything behind”, there will be **many** corner cases that will need to be very carefully and explicitly defined; otherwise, each implementation will inevitably produce different output. See, e.g., [my original example](https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-429447287) with three different behaviors from three browsers, for just the simple case of opacity applied to the parent element.
2. It will allow performant implementations. As far as we can tell, nested backdrop-filters that don’t respect isolation will suffer exponential performance degradation, as each one doubles the required rendering work.
3. It is exactly analogous to <code>mix-blend-mode</code>, and we see no reason to have different behavior for similar operations. In addition, all of the logic that went into making mix-blend-mode respect isolation should also apply to backdrop-filter.

GitHub Notification of comment by mfreed7
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-442275033 using your GitHub account
Received on Wednesday, 28 November 2018 00:45:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:25 UTC