CSS width/height/background-color shows bizarre screen for placeholder canvas that has transferred control to Offscreen |
|||||||
Issue description
When html canvas element (called placeholder canvas) has transferred control to OffscreenCanvas, it uses a SolidColorLayer; when the first OffscreenCanvas commit() happens, the SolidColorLayer is replaced by a SurfaceLayer. All these are very different from a traditional TextureLayer that we use for an html element.
The CSS styles defined for the placeholder canvas mostly will work. But here are the situation when the browser shows bizarre behavior.
#myCanvas {
width: 100%;
height: 100%;
background-color: rgb(241, 241, 241);
}
The background color update, together with the stretching of width and height in the canvas, seems to conflict with the way SurfaceLayer handles a texture
pushed by the commit(). The browser shows four black color corners on the screen and does not perform a repaint unless a resizing happens (See the attached picture, the default Google logo is not removed before the canvas is painted on top of it).
+cc meade, pdr: Do you know where is the code when a CSS stylesheet (in particular, the above three commands) is applied upon an html element? How can we adapt this to an html element that uses a SurfaceLayer?
,
Mar 21 2017
@pdr: I guess cc was not considering the case when the layer is a TextureLayer and so there were some errors of repainting in this case. I'm not sure about the cc invalidation, but we do tell Blink to do a compositing update here (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/CanvasSurfaceLayerBridge.cpp?l=120) when the SurfaceLayer is created or changing size. This problem will not occur if I only use "width=100% height=100%" in css, or if I only use "background-color" in css. Only when both of them get involved in the css then the weird behavior will occur. What's weird about this problem is that since then the SurfaceLayer is no longer capable of rendering valid images for future animation frame. In OffscreenCanvas, we push different images as compositor frame to the Surface in browser (associated to that SurfaceLayer) in an animation frame loop. The painting will become on top of the existing painting. For example, in a bouncing balls animation, we'll see the traces (see snapshot) of balls instead of the balls themselves, in addition to four mysterious black corners. If we run the browser after taking away the CSS definition on the placeholder canvas, the bouncing balls animation will become normal. +cc fserb, ajuma for interest.
,
Mar 21 2017
I've seen similar issues when the corners look like that, but I don't know what causes it. Ajuma may have ideas. I talked with Chris and he said it occurs when you don't send a display list that draws the full layer.
,
Mar 21 2017
Yeah, I've also seen that when we don't have content for the full layer. This looks like we're not clearing the canvas texture to the background color (or clearing it at all) each frame, though I'm not sure how that's supposed to work for offscreen canvas (which bypasses the compositor thread altogether), or why it only happens for certain combinations of style rules.
,
Mar 21 2017
@xlai, these are the two places where style is applied to HTML elements: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Element.cpp?l=1840 https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?l=1774
,
Mar 23 2017
,
Mar 23 2017
,
Mar 24 2017
,
Mar 24 2017
Got it: CompositedLayerMapping::updateContentsOpaque was assuming that the box background was being drawn as a part of the content layer, which is not the case when compositing a placeholder canvas. So when the contents of the canvas are semi-transparent and the background color is opaque, the content layer was improperly marked as opaque.
,
Mar 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9e0bad82923e80164de225930fefe0986c1aa98d commit 9e0bad82923e80164de225930fefe0986c1aa98d Author: junov <junov@chromium.org> Date: Fri Mar 24 22:44:39 2017 Fix the compositing of placeholder canvas backgrounds In CompositedLayerMapping::updateContentsOpaque(), we were falsely assuming that an opaque CSS background made the content layer opaque this was causing rendering artifacts because culling optimizations were kicking in when they should not. BUG= 703673 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2774903003 Cr-Commit-Position: refs/heads/master@{#459583} [add] https://crrev.com/9e0bad82923e80164de225930fefe0986c1aa98d/third_party/WebKit/LayoutTests/fast/canvas/OffscreenCanvas-opaque-background-compositing-expected.html [add] https://crrev.com/9e0bad82923e80164de225930fefe0986c1aa98d/third_party/WebKit/LayoutTests/fast/canvas/OffscreenCanvas-opaque-background-compositing.html [modify] https://crrev.com/9e0bad82923e80164de225930fefe0986c1aa98d/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp [modify] https://crrev.com/9e0bad82923e80164de225930fefe0986c1aa98d/third_party/WebKit/Source/platform/graphics/OffscreenCanvasFrameDispatcherImpl.cpp
,
Mar 27 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by pdr@chromium.org
, Mar 21 2017