Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 563816



Sign in to add a comment
OffscreenCanvas using commit() from worker thread flickers when main thread blocked
Project Member Reported by kbr@chromium.org, Sep 6 Back to list
Chrome Version: 63.0.3207.0 (Official Build) canary (64-bit)
OS: macOS 10.12.5

What steps will reproduce the problem?
(1) Go to https://baicoianu.com/~bai/scratch/offscreencanvasworkertest.html
(2) Click "Block main thread for 5 seconds"
(3) Scroll up and down a little

What is the expected result?

Expect the animation to continue running.


What happens instead?

The animation flickers a little. It looks like it's dropping frames and occasionally rendering the canvas as black.

I think this is a known issue but couldn't find it in the issue tracker. This was reported by mr. doob on Twitter. Justin, could you own this, or reassign it?

 
Cc: fsam...@chromium.org
Status: Assigned
There was a flickering issue in the past. It was resolved.  This one has a slightly different use case with the scrolling and blocking.  Thanks for reporting!
Cc: kylec...@chromium.org
This could be related to surface references. +kylechar.
I just reproduced on macOS Canary 63.0.3207.0. I can see the flicker but Compositing.SurfaceAggregator.SurfaceDrawQuad.MissingSurface UMA shows no missing Surfaces when I go to chrome://histograms. I don't think this is related to surface references.
Owner: xlai@chromium.org
Comment 5 by xlai@chromium.org, Sep 15 (5 days ago)
Labels: Needs-Bisect
So I tried this demo in both Stable Chrome and Canary in Mac and see only the flickering in Canary. I couldn't see obvious difference in stable Chrome. So I guess this might be a regression.
Comment 6 by xlai@chromium.org, Sep 15 (4 days ago)
I didn't update my Chrome so it is the 60.0.3112.113 that's working fine. But 61.0.3163.91, the latest stable Chrome, is showing flickering. Bisecting between this range now.
Comment 7 by xlai@chromium.org, Sep 15 (4 days ago)
Cc: kbr@chromium.org
It is very hard to perform a reliable bisect on this, as the flickering is not easy to detect using raw eyes. I would prefer to look into the code to do a static analysis instead.

Based on my repeated attempts, it seems that this flickering only happens on Mac platform; Linux and Win are all doing right. Also, the problem occurs much less frequently in a high-performance Mac machine (2.7 GHz 12-core, 64GB memory, 3072MB graphics card). The problem is easier to detect in a low-performance Mac machine (2.2 GHz i7 4-core, 8GB memory, 1536MB graphics).

The image looks like an old frame getting painted on the screen. I suspect that this is because some compositor frames are out of order in Mac.

Ken@: are you aware of any other similar issues in Mac platform that have frames displaying in missing/out-of-order fashion?
Comment 8 by kbr@chromium.org, Sep 15 (4 days ago)
Cc: sunn...@chromium.org
Olivia: yes, actually -- see  Issue 765729 . Basically, running that demo with --disable-features=WebGLImageChromium is causing flickering.

Meant to bisect that yesterday, but was focused on fixing the underlying problem with the canvas rendering transparent. Will talk with sunnyps@ who mentioned there was a specific recent CL that might be at fault.

Comment 9 by susanjuniab@chromium.org, Sep 18 (2 days ago)
Cc: susanjuniab@chromium.org
Labels: Needs-Triage-M63 M-63
Able to reproduce the issue on Mac 10.12.6 using chrome stable version 61.0.3163.91 and latest canary 63.0.3218.0 and below is the bisect information.

Bisect Information:
=====================
Good build: 61.0.3161.0	 
Bad Build : 61.0.3162.0	

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/55ed8ccd43eadef318b5e7a6bcf2519b078b1213..a61014fad30efbfc90135865dc7d79299ce7e44d

From the above change log suspecting below change
Review URL: https://chromium.googlesource.com/chromium/src/+/a61014fad30efbfc90135865dc7d79299ce7e44d

The above changelog looks to be irrelevant, as this issue was inconsistent when performing bisect.

Keeping the 'Needs-Bisect' label and requesting Dev for further help in triaging  this issue.

Thanks...!!

Comment 10 by xlai@chromium.org, Yesterday (45 hours ago)
Labels: -M-63 -Needs-Triage-M63
I found another low-end Mac machine to do a more reliable and effective bisecting, and can confirm that the last good commit is 479169 and first bad commit is 479185. All of these commits have already been rolled into stable Chrome.

Looking at the commits in this range https://chromium.googlesource.com/chromium/src/+log/16289b3ef759d892a4058671e0657c016101be23..b46c5f152d4b888cae95e06d26815325133b268a

I feel that the possible culprit CL is "Enable gpu scheduler on waterfall and developer builds." by sunnyps@ but I'm not sure how it caused so. The other CLs are doing formatting, histogram, extension change etc so they look less likely to be the one.

sunnyps@: Could you take a look at this issue to see why this CL is causing a flickering on WebGL canvas on worker? 
Comment 11 by junov@chromium.org, Yesterday (33 hours ago)
@xlai: You could disable the gpu scheduler on your local build to confirm whether this is related to the problem. If this is the case, it could be an indication that sync tokens are being used improperly in OffscreenCanvas code.
Project Member Comment 12 by bugdroid1@chromium.org, Today (11 hours ago)
Comment 13 by susanjuniab@chromium.org, Today (7 hours ago)
Labels: -Needs-Bisect
Removing the Needs-Bisect label as it is Assigned to dev and fix is already landed for this issue.

Thanks..
Sign in to add a comment