Bug 136563

Created attachment 237668 [details] Screenshot (old on left, new on right)

With layer borders on you can see some weird behavior in the pre-r173293 case where we force a layer which is the ancestor of the mix-blend-mode layer to get backing store, but this might be a document-sized layer, so why doesn't blending just blend with the tiles?

I guess the stacking context ancestor of the blending element needs backing store?

Created attachment 237942 [details] Patch

(In reply to comment #3) > I guess the stacking context ancestor of the blending element needs backing store? For regular elements the initial backdrop is rgba(0, 0, 0, 0), so the stacking context can be a layer without backing. However, the root element needs a backing store, because it should have an initial backdrop with white opaque content. I uploaded a patch that should fix the problem.

Simon, I didn’t want to r+ without you weighing in. Can you review?

Does this work if the body background is not white?

Created attachment 238178 [details] Patch

The root renderer will get its own backing store when body has a background-color, so blending should work in this case, even without this fix. I added a couple of tests proving that blending a composited child with body works in both cases: (1) when body has a background color and (2) when body doesn't have a background-color, but the child should blend with the default white.

Created attachment 238382 [details] Another testcase I still don't understand the expected behavior here. In this testcase, explicitly setting a background color on the parent element changes behavior. I don't see how that can be avoided given how we interact with Core Animation, but it seems contrary to spec'd behavior.

Which spec are you referring to? The right behavior is the old one from the second attachment: https://bugs.webkit.org/attachment.cgi?id=237668 - an element that is not isolated, should blend with the page's white background. This white background is not always painted within the root layer, which is the actual stacking context for those non-isolated elements. If we force the root renderer to get a backing store, it will become responsible for painting the background for the entire canvas, including the base white color.

Are you saying that the test case shows correct behavior (with the patch applied)? Seems surprising, given that a non-compositing implementation would, I think, show different behavior.

(In reply to comment #12) > Are you saying that the test case shows correct behavior (with the patch applied)? Seems surprising, given that a non-compositing implementation would, I think, show different behavior. I've just tried it with the software path and it gives me the same result. Why are you suspecting them to be different?

Do all three have the same appearance?

I'm sorry, I thought you were referring to the original test case. In the "Another testcase", you have three parent elements, each of them isolating its children. 1) Parent with transparent background (no backing store) - the backdrop for blending will be transparent. 2) Parent with backing store - the backdrop for blending is transparent, except for the area with text, which we don't overlap. 3) Parent with white background - blending occurs with the white background-color. In this test case all blending boxes have regular isolating divs, therefore they cannot have access to the content outside their parent, including the base background white color. This patch only fixes the case when the isolating layer is the root layer. This test case should not be affected by the patch. Let's assume all the boxes were children of body, then the three shapes would have the same appearance: the first two should blend with the base background white, and the third with the white background-color.

Fair enough. Seems super confusing for authors.

Comment on attachment 238178 [details] Patch Clearing flags on attachment: 238178 Committed r173867: <http://trac.webkit.org/changeset/173867>

All reviewed patches have been landed. Closing bug.