Image on WebGL canvas disappears during interaction with Blockly editor on the page
Reported by
pavel.ka...@delightex.com,
Oct 31 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce the problem: 1. Open attached html page in Chrome on os x 2. Switch back and forth between "Misc" and "Functions" section of Blockly multiple times What is the expected behavior? WebGL triangles on the left of the page are visible. What went wrong? WebGL triangles on the left of the page suddenly disappeare. The appear if you resize the page or hover page structure on "Elements" tab of chrome developer tools. Please see attached video. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 53.0.2785.143 Channel: n/a OS Version: OS X 10.12.1 Flash Version: Shockwave Flash 23.0 r0 I am are not sure if this is Chrome of Blockly issue: though, attached case works perfectly fine in Firefox and Safari, and in Chrome under Windows. But it is easily reproduced in Chrome on our MacBooks.
,
Oct 31 2016
That is also reproducible in 56.0.2905.0 canary (64-bit).
,
Oct 31 2016
just noticed that I reported this issue against old 53 version. just updated to the latest stable 54.0.2840.71 (64-bit) and still can reproduce it here.
,
Oct 31 2016
i've just ran some bisection, was not sure where to start, did it like this: python bisect-builds.py -a mac -g 328834 -b 428834 --use-local-cache -- --no-first-run --user-data-dir=/tmp http://appr.me/misc/reduced.html got following result: You are probably looking for a change made after 391648 (known good), but no later than 391657 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/994570aa6d910bcf0f0fd54c0beb52b3daf5fe23..5079a895f21988d6983b475874d491f412288678
,
Oct 31 2016
with #enable-gpu-rasterization set to "Disabled" in chrome://flags the issue goes away.
,
Nov 1 2016
Thanks for triaging this to this point. On my MacBook Pro laptop with NVIDIA GPU I can reproduce the disappearing canvas problem. Passing --disable-gpu-rasterization on the command line makes the problem go away. Setting "preserveDrawingBuffer: true" in the context creation attributes has no effect. Eric, could you take a look at this given that it seems to be caused by GPU rasterization?
,
Nov 1 2016
Thanks for all the triage! So, I think I know what's triggering this - when the SVG is added, the page switches from being "suitable for GPU raster" to not-suitable. This causes us to switch from GPU raster to SW raster or MSAA GPU raster, both of which cause us to re-rasterize and re-composite the frame. For some reason, we lose the WebGL content at this point. I'll look into this more tomorrow.
,
Nov 1 2016
I filed http://crbug.com/661335 before I found this bug. The two bugs appear to be related.
,
Nov 1 2016
I'm upgrading this to P1 as it's been noticed by a significant customer (Figma).
,
Nov 1 2016
Issue 661335 has been merged into this issue.
,
Nov 1 2016
We should be able to write a pixel test for this pretty easily; render a simple WebGL canvas, add some SVG element into the DOM, and expect that a pixel captured from the middle of the WebGL canvas is the appropriate color, and not white.
,
Nov 2 2016
Eric, is there any workaround for this bug? For example, can customers add a single-pixel SVG element to their pages at the beginning of time to work around it?
,
Nov 2 2016
Yup, that would be a reasonable workaround - note that the SVG has to be complex enough to trip our veto. For instance, the SVG in the example, scaled to 1x1px prevents the issue from occurring. The fix for this is pretty straightforward, should land soon and I'll merge to 55.
,
Nov 2 2016
I'll add a pixel test for this tomorrow as well. Good suggestion kbr
,
Nov 2 2016
To make the workaround easier to implement, here's a 1x1 svg (taken from the example) which will trigger the veto. Dropping this somewhere (visible) on a page should prevent this issue from appearing. Note that the visible portion of the SVG is fully transparent, so this should be pretty unobtrusive. <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1px" height="1px"> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g> <g transform="translate(16,179)"> <path fill="#995ba5" d="m 0,8 A 8,8 0 0,1 8,0 H 15 l 6,4 3,0 6,-4 H 40 H 136.64189910888672 v 35 H 29.5 l -6,4 -3,0 -6,-4 H 8 a 8,8 0 0,1 -8,-8 z M 47.832489013671875,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z M 126.64189910888672,5 h -14.5 v 5 c 0,10 -8,-8 -8,7.5 s 8,-2.5 8,7.5 v 6 h 14.5 z"></path> </g></svg> Note that the path does need to be complex for this workaround to work - I tried paring down the SVG here and found that making it simpler prevented it from working.
,
Nov 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7cedb549a0624a5a592bb592c1a828e52623fcb9 commit 7cedb549a0624a5a592bb592c1a828e52623fcb9 Author: ericrk <ericrk@chromium.org> Date: Wed Nov 02 19:03:44 2016 Don't free non-tile resources on GPU rasterization toggle Currently we free all tree resources when GPU rasterization is toggled. This causes problems for non-tile resources as these resources: a) Are not impacted by GPU raster and don't need to be re-rasterized. b) Are not trivially re-creatable, leading to them disappearing. This change adds a new function ReleaseTileResources, which is used in place of ReleaseResources when only tile resources need to be freed. It also renames RecreateResources to RecreateTileResources, as we only implemented this function for picture layers. BUG= 660929 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2468023002 Cr-Commit-Position: refs/heads/master@{#429354} [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/layer_impl.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/layer_impl.h [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/picture_layer_impl.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/picture_layer_impl.h [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/picture_layer_impl_unittest.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/layers/texture_layer_impl_unittest.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/test/fake_picture_layer_impl.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/test/fake_picture_layer_impl.h [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/trees/layer_tree_host_impl.h [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/trees/layer_tree_impl.cc [modify] https://crrev.com/7cedb549a0624a5a592bb592c1a828e52623fcb9/cc/trees/layer_tree_impl.h
,
Nov 2 2016
,
Nov 3 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Nov 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/64edcb17468821037530b22c903bdda22d179473 commit 64edcb17468821037530b22c903bdda22d179473 Author: Eric Karl <ericrk@chromium.org> Date: Thu Nov 03 18:31:09 2016 Don't free non-tile resources on GPU rasterization toggle Currently we free all tree resources when GPU rasterization is toggled. This causes problems for non-tile resources as these resources: a) Are not impacted by GPU raster and don't need to be re-rasterized. b) Are not trivially re-creatable, leading to them disappearing. This change adds a new function ReleaseTileResources, which is used in place of ReleaseResources when only tile resources need to be freed. It also renames RecreateResources to RecreateTileResources, as we only implemented this function for picture layers. BUG= 660929 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2468023002 Cr-Commit-Position: refs/heads/master@{#429354} (cherry picked from commit 7cedb549a0624a5a592bb592c1a828e52623fcb9) Review URL: https://codereview.chromium.org/2480533002 . Cr-Commit-Position: refs/branch-heads/2883@{#442} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/layer_impl.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/layer_impl.h [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/picture_layer_impl.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/picture_layer_impl.h [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/picture_layer_impl_unittest.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/layers/texture_layer_impl_unittest.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/test/fake_picture_layer_impl.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/test/fake_picture_layer_impl.h [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/trees/layer_tree_host_impl.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/trees/layer_tree_host_impl.h [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/trees/layer_tree_impl.cc [modify] https://crrev.com/64edcb17468821037530b22c903bdda22d179473/cc/trees/layer_tree_impl.h
,
Nov 3 2016
,
Nov 8 2016
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by pavel.ka...@delightex.com
, Oct 31 201647.4 KB
47.4 KB View Download