Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Owner:
Closed: Mar 27
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Mac
Pri: 2
Type: Bug

Blocking:
issue 563816



Sign in to add a comment
CSS width/height/background-color shows bizarre screen for placeholder canvas that has transferred control to Offscreen
Project Member Reported by xlai@chromium.org, Mar 21 Back to list
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?
 
canvas.css
323 bytes View Download
OffscreenCanvas-commit-main.html
604 bytes View Download
Screenshot from 2017-03-21 11:23:35.png
41.7 KB View Download
This probably happens in LayoutReplaced::layout when the width/height is calculated. Could the bug be that we are not telling cc to repaint the right area? If so, we might need to issue additional invalidations.
Cc: fs...@chromium.org ajuma@chromium.org
@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.
Screenshot from 2017-03-17 12:11:34.png
1.2 MB View Download
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.
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.
Components: Blink>Compositing
Blocking: 563816
Labels: -Pri-3 Pri-2
Owner: junov@chromium.org
Status: Assigned
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.
Project Member Comment 10 by bugdroid1@chromium.org, Mar 24
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

Status: Fixed
Sign in to add a comment