Closed Bug 947121 Opened 9 years ago Closed 9 years ago

No blending for the element with mix-blend-mode when his child has opacity less than 1

Categories

(Core :: Layout, defect, P3)

x86_64
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 952051

People

(Reporter: mbudaes, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

1.75 KB, application/x-zip-compressed
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Steps to reproduce:

Have an element with mix-blend-mode other than normal and a child of the above element with opacity less than one.


Actual results:

No blending for the element with mix-blend-mode.


Expected results:

Blending applied.
I was using Firefox nightly build "28.0a1 (2013-12-05)" with layout.css.mix-blend-mode flag enabled.
OS: Windows 7 → All
Hardware: x86_64 → All
Hardware: All → x86_64
Component: Untriaged → Layout
Product: Firefox → Core
Flags: needinfo?(cabanier)
Priority: -- → P5
Keywords: testcase
Seems like this probably blocks shipping mix-blend-mode.  (I don't see a bug tracking shipping mix-blend-mode, though.)
Priority: P5 → P3
mix-blend-mode is not ready for shipping yet. Unfortunately I have to work on another project this week so I likely won't be able to look into this until next week.
Flags: needinfo?(cabanier)
(In reply to mire from comment #1)
> I was using Firefox nightly build "28.0a1 (2013-12-05)" with
> layout.css.mix-blend-mode flag enabled.
Can't reproduce on 29.0a1 (2013-12-15), Win 7 x64.
Just checked on (2013-12-15), Win 7 x64. This is still an issue.
The actual file (mix-blend-mode-child-of-blended-has-opacity.html) doesn't match the expected file(reference/mix-blend-mode-child-of-blended-has-opacity-ref.html).
Sorry, I seem to misunderstood the issue. Confirmed on 29.0a1 (2013-12-15), Win 7 x64.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 952643
This issue is a duplicate of issue 952051. Even though the problem described in this issue seems different from the one described in bug 952051, they have the same root cause.

The difference in behavior between having a child with opacity, and not having one, comes from the logic used to determine whether the container layer for the blending item uses an intermediate surface.

  mUseIntermediateSurface =
    GetMaskLayer() ||
    GetForceIsolatedGroup() ||
    (GetMixBlendMode() != gfxContext::OPERATOR_OVER && HasMultipleChildren()) ||
    (GetEffectiveOpacity() != 1.0 && (HasMultipleChildren() || hasSingleBlendingChild));

When the child element does not have opacity (<1) set, the container layer associated with the parent  blending element is considered to have a single child (and does not need a surface).

When opacity is added to the child element, the container layer for the parent blending element will have multiple children and will use an intermediate surface as a consequence.

Since container layers that use intermediate surfaces do not take into consideration the blending operator when calling FlushGroup (as per bug 952051), the blending does not happen.

The fix will be made in bug 952051, changing FlushGroup to take into account the blending operator.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.