When possible, webkit should try to use core graphics to implement blending since it is more memory efficient than using compositing layers.
Created attachment 169276 [details] out of date
Created attachment 223711 [details] Patch V1
Created attachment 223714 [details] Patch V2
Comment on attachment 223714 [details] Patch V2 I don't think you can simply remove the composited code path. If a blended element is on top of anything composited, then the blended element needs to be composited. If the blended element is itself composited, then everything under it needs to be composted for blending to work.
(In reply to comment #4) > (From update of attachment 223714 [details]) > I don't think you can simply remove the composited code path. > > If a blended element is on top of anything composited, then the blended element needs to be composited. > If the blended element is itself composited, then everything under it needs to be composted for blending to work. Your statements are correct. Both composited and non-composited code paths should be in place. Previous to this, only the composited path was in place, and any blended element would force the creation of a composited layer. With this patch, this behaviour is altered: if an element with blend-mode has a property, parent or child that forces compositing, the hardware path is followed. Otherwise, the non-compositing implementation in this patch is used.
Also, I'm sorry if this wasn't clear enough, the intention is to have both a composited and non-composited code path. We are thinking it may be more performant not to force using the hardware path when possible.
Comment on attachment 223714 [details] Patch V2 The patch itself looks fine, but I have a number of questions. What happens if a composited element is drawn under something that is blending? (not in the same hierarchy) Similarly, what happens if a child of a blending element gets a compositing layer? How does it contribute to the blend?
(In reply to comment #7) > (From update of attachment 223714 [details]) > The patch itself looks fine, but I have a number of questions. > > What happens if a composited element is drawn under something that is blending? (not in the same hierarchy) The mix-blend-mode (-webkit-blend-mode) property creates a stacking context. This means that in this case, the blending layer gets promoted with the IndirectCompositingForOverlap reason and the blending operation is performed. I'll add a test to the patch for this. > > Similarly, what happens if a child of a blending element gets a compositing layer? How does it contribute to the blend? As stated by the spec, the contents of an element (including child elements) must blend with the underlying stacking context. In this case, if a child layer gets a compositing layer, the blending layer is also promoted and the blending operation is performed correctly. This is tested in the patch in |blend-mode-with-composited-descendant-should-have-layer.html|.
Created attachment 223830 [details] Patch V3 Added a test that validates the promotion of a blended element when overlapping a composited element from a different hierarchy.
Comment on attachment 223830 [details] Patch V3 View in context: https://bugs.webkit.org/attachment.cgi?id=223830&action=review > LayoutTests/css3/compositing/blend-mode-blended-element-overlapping-composited-sibbling-should-have-compositing-layer.html:1 > +<!--DOCTYPE HTML--> <!DOCTYPE html> > LayoutTests/css3/compositing/blend-mode-blended-element-overlapping-composited-sibbling-should-have-compositing-layer.html:9 > + .accelerated_sibbling { I usually use the class name "composited". > LayoutTests/css3/compositing/blend-mode-blended-element-overlapping-composited-sibbling-should-have-compositing-layer.html:19 > +<div class="accelerated_sibbling"></div> sibling
Created attachment 223957 [details] Patch for landing
Comment on attachment 223957 [details] Patch for landing Clearing flags on attachment: 223957 Committed r163955: <http://trac.webkit.org/changeset/163955>