Testcase (not yet reduced completely, but should be easy to do so):

http://jsfiddle.net/m757LkaL/

Expected:

More than 2 icons should appear.

Actual: only 2.

I have put will-change: transform and a background color on the various
elements with left:-10000. Because of the containing opacity, and that there are more than
one of them, we end up with a render surface for all of them, and it's messed up.

Must load with --enable-prefer-compositing-to-lcd-text I think.

Ali could you look? Something is up maybe in the property trees?
Tien-ren also thinks this is perhaps related to  crbug.com/664091 .

This is a high priority bug for gmail. See internal issue 32060115.

This repros on Linux with --enable-prefer-compositing-to-lcd-text, but not on Mac. Not yet sure if the layer tree is somehow different on Mac.

At first glance, this looks like bad draw transforms or drawable content rects. Need to minimize the test some more first.

Bisected to https://codereview.chromium.org/1960543002 ("Optimize render passes with single quads").

I think I know what's happening. The render pass optimization from #5 works correctly when the texture for the single quad is of the same size as the texture we would get for the render pass if we didn't optimize it out (since when the optimization is enabled for a pass, GLRenderer::DrawRenderPassQuad uses the quad's texture in place of the pass' texture).

GLRenderer::CanPassBeDrawnDirectly does check if the quad is positioned at the pass' origin. But in the buggy case the pass' own output_rect's origin isn't (0, 0) in its space, it instead has negative x and y coordinates.

e.g. the pass' output rect is -56,-20 77x41, while the quad rect in pass space is 0,0 21x21. 

So then we're taking the quad's 21x21 texture and positioning it the way we'd position the 77x41 texture for the pass, which means the quad's content is shifted up and to the left, since it's actually being drawn at -56,20 in pass space instead of at 0,0.

The safest fix (particularly for merging back) would be to add this case (the quad rect being different from the the pass' output rect) to list of conditions that GLRenderer::CanPassBeDrawnDirectly blacklists.

Also, GLRenderer::CanPassBeDrawnDirectly always returns false on Mac, which explains why this bug doesn't repro there.

 Issue 664091  has been merged into this issue.

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

commit 7faf8fc181b5d98c6007495a8944ff0be3aeeb90
Author: ajuma <ajuma@chromium.org>
Date: Fri Dec 09 01:17:17 2016

cc: Only use single quad pass optimization when quad rect matches pass rect

GLRenderer::CanPassBeDrawnDirectly checks if a pass' only quad is
positioned at (0, 0) in pass space, but this doesn't guarantee that
the quad will be positioned at the top left corner of the pass' texture,
since the pass' own texture isn't necessarily positioned at (0, 0) in pass
space. In this situation, using the quad's texture in place of the pass's
texture results in incorrect positioning of the quad's contents. To fix this,
this CL adds a check that the quad rect matches the pass' output rect.

BUG= 671773 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/7faf8fc181b5d98c6007495a8944ff0be3aeeb90/cc/output/gl_renderer.cc
[add] https://crrev.com/7faf8fc181b5d98c6007495a8944ff0be3aeeb90/cc/test/data/translated_blue_green_alpha_gl.png
[add] https://crrev.com/7faf8fc181b5d98c6007495a8944ff0be3aeeb90/cc/test/data/translated_blue_green_alpha_sw.png
[modify] https://crrev.com/7faf8fc181b5d98c6007495a8944ff0be3aeeb90/cc/trees/layer_tree_host_pixeltest_filters.cc

Can we please add the proper OS tags here?

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit b51cb6ccaf15340a6fb968f61b907bd17fd15d81
Author: Ali Juma <ajuma@chromium.org>
Date: Mon Dec 12 15:29:05 2016

cc: Only use single quad pass optimization when quad rect matches pass rect

GLRenderer::CanPassBeDrawnDirectly checks if a pass' only quad is
positioned at (0, 0) in pass space, but this doesn't guarantee that
the quad will be positioned at the top left corner of the pass' texture,
since the pass' own texture isn't necessarily positioned at (0, 0) in pass
space. In this situation, using the quad's texture in place of the pass's
texture results in incorrect positioning of the quad's contents. To fix this,
this CL adds a check that the quad rect matches the pass' output rect.

BUG= 671773 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2558393002
Cr-Commit-Position: refs/heads/master@{#437402}
(cherry picked from commit 7faf8fc181b5d98c6007495a8944ff0be3aeeb90)

Review-Url: https://codereview.chromium.org/2568133002 .
Cr-Commit-Position: refs/branch-heads/2924@{#454}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/b51cb6ccaf15340a6fb968f61b907bd17fd15d81/cc/output/gl_renderer.cc
[add] https://crrev.com/b51cb6ccaf15340a6fb968f61b907bd17fd15d81/cc/test/data/translated_blue_green_alpha_gl.png
[add] https://crrev.com/b51cb6ccaf15340a6fb968f61b907bd17fd15d81/cc/test/data/translated_blue_green_alpha_sw.png
[modify] https://crrev.com/b51cb6ccaf15340a6fb968f61b907bd17fd15d81/cc/trees/layer_tree_host_pixeltest_filters.cc

Verified this issue on Mac 10.12.1, Win-10 and Ubuntu 14.04 using chrome beta version #56.0.2924.28 as per comment #1 and #2.

Observed that the fix is working as expected.

Attaching screencast for reference.

Hence, adding the verified labels.

Deleted: 671773.ogv 1.7 MB

	671773.ogv 1.7 MB View Download

 Issue 649490  has been merged into this issue.