Bug 99119

Summary: Implement a non-compositing path for blending
Product: WebKit Reporter: Rik Cabanier <cabanier>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: cabanier, commit-queue, dino, esprehn+autocc, glenn, kondapallykalyan, krit, mihnea, mitica, simon.fraser, WebkitBugTracker
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: All   
Bug Depends on: 99135, 129305    
Bug Blocks: 95614    
Attachments:
Description Flags
out of date
none
Patch V1
none
Patch V2
none
Patch V3
simon.fraser: review+
Patch for landing none

Description Rik Cabanier 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.
Comment 1 Rik Cabanier 2012-10-17 15:36:09 PDT
Created attachment 169276 [details]
out of date
Comment 2 Mihai Tica 2014-02-10 07:37:23 PST
Created attachment 223711 [details]
Patch V1
Comment 3 Mihai Tica 2014-02-10 08:09:24 PST
Created attachment 223714 [details]
Patch V2
Comment 4 Simon Fraser (smfr) 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.
Comment 5 Mihai Tica 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.
Comment 6 Mihai Tica 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.
Comment 7 Dean Jackson 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?
Comment 8 Mihai Tica 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|.
Comment 9 Mihai Tica 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.
Comment 10 Simon Fraser (smfr) 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
Comment 11 Mihai Tica 2014-02-12 02:30:35 PST
Created attachment 223957 [details]
Patch for landing
Comment 12 WebKit Commit Bot 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>