New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 660600 link

Starred by 8 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: 2016-11-07
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Opacity is applied twice when using hardware acceleration

Reported by m...@janpaulposma.nl, Oct 28 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Example URL:
http://codepen.io/janpaul123/pen/QKReyb

Steps to reproduce the problem:
1. Open a webpage with the following HTML:

<div style="opacity: 0.5;">
  <img src="https://dummyimage.com/256x256/000/fff.jpg" style="transform: translate3d(0, 0, 0);">
</div>
<img src="https://dummyimage.com/256x256/000/fff.jpg"  style="opacity: 0.5;">

2. Observe that the two images look different.

What is the expected behavior?
They should look the same — both with 0.5 opacity.

What went wrong?
It looks like the first one has the opacity applied twice.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 53.0.2785

Does this work in other browsers? Yes

Chrome version: 56.0.2903.0  Channel: canary
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0

Found on remix.com.

— Chris Hasson <chris@remix.com> and Jan Paul Posma <janpaul@remix.com>
 
Screen Shot 2016-10-28 at 16.36.59.png
56.8 KB View Download

Comment 1 Deleted

Comment 2 by tkent@chromium.org, Oct 30 2016

Components: -Blink Blink>Paint
Components: -Blink>Paint Internals>Compositing>Images
Labels: Needs-Bisect
NextAction: 2016-11-07
Status: Untriaged (was: Unconfirmed)
This is Mac specific. It does not repro on linux or Windows.

Bisect is needed. Adding NextAction to make sure that occurs.

Comment 4 by ericrk@chromium.org, Oct 31 2016

Owner: ericrk@chromium.org
Status: Assigned (was: Untriaged)
Taking a look.

Comment 5 by ericrk@chromium.org, Oct 31 2016

Cc: ericrk@chromium.org
Components: -Internals>Compositing>Images Internals>Compositing
Owner: erikc...@chromium.org
Did a bisect, the change which caused this behavior is:

crrev.com/2265273002 - Re-enable promotion of RenderPassDrawQuads to CALayers

Not necessarily sure that we're applying opacity twice - this may be a case that we're just supplying the opacity to CA in the wrong way or with the wrong value.

It's likely that the issue is in the CA path, as other OSes don't show this issue.

Also note that this is independent of GPU raster (Hardware acceleration in the bug title refers to hardware accelerated compositing).

erikchen@, can you take a look?
Cc: ccameron@chromium.org
ericrk: Thanks for tracking this down. I bet CopyRenderPassDrawQuadToOverlayResource applies the opacity, and then 
"""
4045   gl_->ScheduleCALayerSharedStateCHROMIUM(                                      
4046       ca_layer_overlay->shared_state->opacity, is_clipped, clip_rect,           
4047       sorting_context_id, gl_transform);  
"""

applies the opacity again.
Labels: -Needs-Bisect -Via-Wizard-Content M-55 ReleaseBlock-Stable
This bug is present on M54 (stable). This seems unlikely to be worth a refresh, but we should merge to M55.
Project Member

Comment 8 by bugdroid1@chromium.org, Nov 1 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4a9cceac5f1883f48b564ad277d3d39cdd9f8615

commit 4a9cceac5f1883f48b564ad277d3d39cdd9f8615
Author: erikchen <erikchen@chromium.org>
Date: Tue Nov 01 18:33:25 2016

mac: Fix bug where opacity is applied twice on RenderPassDrawQuads.

When using the CoreAnimation compositor, RenderPassDrawQuads are copied to an
IOSurface. The opacity is already applied there, so there's no need for the
CoreAnimation Compositor to apply it again.

BUG= 660600 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2467643002
Cr-Commit-Position: refs/heads/master@{#429060}

[modify] https://crrev.com/4a9cceac5f1883f48b564ad277d3d39cdd9f8615/cc/output/gl_renderer.cc
[modify] https://crrev.com/4a9cceac5f1883f48b564ad277d3d39cdd9f8615/content/test/data/gpu/filter_effects.html
[modify] https://crrev.com/4a9cceac5f1883f48b564ad277d3d39cdd9f8615/content/test/gpu/gpu_tests/pixel_test_pages.py

Status: Fixed (was: Assigned)
Labels: Merge-Request-55

Comment 11 by dimu@chromium.org, Nov 2 2016

Labels: -Merge-Request-55 Merge-Approved-55 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M55 (branch: 2883)
Project Member

Comment 12 by bugdroid1@chromium.org, Nov 2 2016

Labels: -merge-approved-55 merge-merged-2883
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8bebab8c7bad3e5c3e76ed8b83963ccd561dd522

commit 8bebab8c7bad3e5c3e76ed8b83963ccd561dd522
Author: erikchen <erikchen@chromium.org>
Date: Wed Nov 02 18:06:08 2016

[Merge to 2883] mac: Fix bug where opacity is applied twice on RenderPassDrawQuads.

> When using the CoreAnimation compositor, RenderPassDrawQuads are copied to an
> IOSurface. The opacity is already applied there, so there's no need for the
> CoreAnimation Compositor to apply it again.
>
> BUG= 660600 
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
>
> Review-Url: https://codereview.chromium.org/2467643002
> Cr-Commit-Position: refs/heads/master@{#429060}
> (cherry picked from commit 4a9cceac5f1883f48b564ad277d3d39cdd9f8615)

Review URL: https://codereview.chromium.org/2469893003 .

Cr-Commit-Position: refs/branch-heads/2883@{#423}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/8bebab8c7bad3e5c3e76ed8b83963ccd561dd522/cc/output/gl_renderer.cc
[modify] https://crrev.com/8bebab8c7bad3e5c3e76ed8b83963ccd561dd522/content/test/data/gpu/filter_effects.html
[modify] https://crrev.com/8bebab8c7bad3e5c3e76ed8b83963ccd561dd522/content/test/gpu/gpu_tests/pixel_test_pages.py

Project Member

Comment 13 by bugdroid1@chromium.org, Nov 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/18cdab375861899edb98261fec71f14360a1934a

commit 18cdab375861899edb98261fec71f14360a1934a
Author: erikchen <erikchen@chromium.org>
Date: Wed Nov 02 19:04:35 2016

Update expectations for filter effect pixel tests.

Reference images look correct:
gs://chromium-gpu-archive/reference-images/Pixel_CSSFilterEffects_NoOverlays_v3_mac_8086_0a2e_msaa.png
gs://chromium-gpu-archive/reference-images/Pixel_CSSFilterEffects_v3_mac_8086_0a2e_msaa.png

BUG= 660600 ,  581526 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2472533002
Cr-Commit-Position: refs/heads/master@{#429355}

[modify] https://crrev.com/18cdab375861899edb98261fec71f14360a1934a/content/test/gpu/gpu_tests/pixel_expectations.py

 Issue 662072  has been merged into this issue.
Cc: erikc...@chromium.org hdodda@chromium.org
 Issue 662764  has been merged into this issue.
Labels: TE-Verified-55.0.2883.44 TE-Verified-M55
Tested the issue on MacBook Pro (Retina, Mid 2012) using chrome version 55.0.2883.44 with the URL http://codepen.io/janpaul123/pen/QKReyb
Observed that both images are looking same.
Please find the attached screen shot for the same.

Adding TE-Verified labels.

Thanks,
Screen Shot 2016-11-09 at 3.03.27 PM.png
82.2 KB View Download
Cc: bugsnash@chromium.org rbasuvula@chromium.org
 Issue 662532  has been merged into this issue.
 Issue 669477  has been merged into this issue.

Sign in to add a comment