RESOLVED FIXED 99119
Implement a non-compositing path for blending 
https://bugs.webkit.org/show_bug.cgi?id=99119
Summary Implement a non-compositing path for blending
Rik Cabanier
Reported 2012-10-11 17:01:09 PDT
When possible, webkit should try to use core graphics to implement blending since it is more memory efficient than using compositing layers.
Attachments
out of date (808.94 KB, patch)
2012-10-17 15:36 PDT, Rik Cabanier 		no flags
DetailsFormatted DiffDiff
Patch V1 (1.84 MB, patch)
2014-02-10 07:37 PST, Mihai Tica 		no flags
DetailsFormatted DiffDiff
Patch V2 (1.84 MB, patch)
2014-02-10 08:09 PST, Mihai Tica 		no flags
DetailsFormatted DiffDiff
Patch V3 (1.84 MB, patch)
2014-02-11 02:06 PST, Mihai Tica 		simon.fraser: review+
DetailsFormatted DiffDiff
Patch for landing (1.84 MB, patch)
2014-02-12 02:30 PST, Mihai Tica 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Rik Cabanier
Comment 1 2012-10-17 15:36:09 PDT
Created attachment 169276 [details] out of date
Mihai Tica
Comment 2 2014-02-10 07:37:23 PST
Created attachment 223711 [details] Patch V1
Mihai Tica
Comment 3 2014-02-10 08:09:24 PST
Created attachment 223714 [details] Patch V2
Simon Fraser (smfr)
Comment 4 2014-02-10 09:02:03 PST
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.
Mihai Tica
Comment 5 2014-02-10 09:26:13 PST
(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.
Mihai Tica
Comment 6 2014-02-10 09:39:13 PST
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.
Dean Jackson
Comment 7 2014-02-10 10:03:25 PST
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?
Mihai Tica
Comment 8 2014-02-11 01:24:43 PST
(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|.
Mihai Tica
Comment 9 2014-02-11 02:06:38 PST
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.
Simon Fraser (smfr)
Comment 10 2014-02-11 09:01:50 PST
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
Mihai Tica
Comment 11 2014-02-12 02:30:35 PST
Created attachment 223957 [details] Patch for landing
WebKit Commit Bot
Comment 12 2014-02-12 04:35:36 PST
Comment on attachment 223957 [details] Patch for landing Clearing flags on attachment: 223957 Committed r163955: <http://trac.webkit.org/changeset/163955>
Note You need to log in before you can comment on or make changes to this bug.