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

Issue metadata

Status: Fixed
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 2
Type: Bug

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, Mar 21 2017 Back to list

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?
323 bytes View Download
604 bytes View Download
Screenshot from 2017-03-21 11:23:35.png
41.7 KB View Download

Comment 1 by, Mar 21 2017

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.

Comment 2 by, 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 ( 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

Comment 3 by, 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.

Comment 4 by, 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.

Comment 6 by, Mar 23 2017

Components: Blink>Compositing

Comment 7 by, Mar 23 2017

Blocking: 563816
Labels: -Pri-3 Pri-2

Comment 8 by, Mar 24 2017

Status: Assigned (was: Untriaged)

Comment 9 by, 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.
Project Member

Comment 10 by, Mar 24 2017

The following revision refers to this bug:

commit 9e0bad82923e80164de225930fefe0986c1aa98d
Author: junov <>
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 

Cr-Commit-Position: refs/heads/master@{#459583}


Comment 11 by, Mar 27 2017

Status: Fixed (was: Assigned)

Sign in to add a comment