WebGL canvas sometimes flickers black in Chrome app
Reported by
a...@scirra.com,
Nov 22 2016
|
|||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Steps to reproduce the problem: Construct 2 users are reporting that in the context of a Chrome app (or extension window or whatever it's called now), the canvas sometimes flickers black. It seems to correlate with audio playback (so maybe some kind of thread timing issue?). In the Chrome browser itself, it appears it never happens - it only occurs when loaded as a Chrome app. HTML version which does *not* reproduce the issue: https://www.scirra.com/labs/bugs/flickerbughtml/ Identical version wrapped as a Chrome app which does reproduce the issue: attached to this report. The issue is sporadic and sometimes you have to wait or try a few times. What is the expected behavior? The canvas should never flicker and always render, like it does in the HTML version. What went wrong? Occasionally the screen flickers black, which is distracting for games. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 54.0.2840.99 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 This was originally reported by Construct 2 users here: https://www.scirra.com/forum/screen-flickers_t183744 where several users say they were able to reproduce it. One user provided a video of the issue affecting their game: https://www.youtube.com/watch?v=m7hQElQKO0M
,
Nov 22 2016
The fact that HTML version works fine and the extension has the problem, makes me feel that there is related to how extension works. Maybe resource loading?
,
Nov 22 2016
They are pretty much identical in terms of resources/code. I think the key difference is it uses an extension window vs. browser tab.
,
Nov 22 2016
,
Nov 22 2016
I can't immediately reproduce with any of: Windows: 54.0.2840.99 (Official Build) m (64-bit) 57.0.2925.0 (Official Build) canary (64-bit) macOS: 57.0.2926.0 (Official Build) canary (64-bit) Ashley, can you reproduce with Canary? Is closing and reopening the extension window sufficient to repro? How long does it usually take? Also, on Windows, after pressing escape to take the fullscreen extension window back to windowed mode, I can never get it to go fullscreen in the same way again. Ashley, can you add a button or something to the app to support this? CC'ing jbauman@ in case this is something related to surfaces on Windows since it seems to affect only full-screen mode.
,
Nov 22 2016
You could check and see if it happens with the --disable-direct-composition command-line flag.
,
Nov 22 2016
I just tested with the --disable-direct-composition flag and it fixes the issue. Can't see any screen flickering any more. Could you tell or point to place where I can read about this option? What does it exactly do? Can we expect any performance drop or any other disadvantages while using this option?
,
Nov 22 2016
There's no documentation of that, as it's not really intended to be a user-visible feature. Adding the flag disables the use of DirectComposition, which means that performance and power consumption will get a bit worse (maybe by 10%). I can't seem to reproduce the issue on my Windows 10 machine on Canary. Could anyone who can reproduce this attach the contents of chrome://gpu from Chrome?
,
Nov 23 2016
Hmm...presumably Optimus laptop, dual Intel HD 4000 and NVIDIA GeForce GT 635M GPUs. Should we blacklist DirectComposition on Optimus configurations on Windows? These are no longer being made, correct?
,
Nov 23 2016
I should add that the bug reproduce here only in fullscreen.
,
Nov 23 2016
The previous comment is with Canary and Win10
,
Nov 23 2016
PS: OP's chrome app works well here, but the attachment in #12 doesn't.
,
Nov 23 2016
No I don't have an Optimus laptop. It's a Lenovo G780 Intel Core i7-3632QM + Intel HD 4000 and NVIDIA GeForce GT 635M GPUs.
,
Nov 23 2016
With the version in comment #12 I can reproduce this with my intel-gpu-only laptop, so it's not related to optimus.
,
Nov 23 2016
Reporter@ - Could you please provide a sample URL in which the issue was reported. This will help in triaging the issue further. Thanks...!!
,
Nov 23 2016
,
Nov 27 2016
Hi, ive encountered the same problem and this issue is currently holding us back from releasing our game. if i can be of any help or can provide needed information let me now. attached you find my system specs.
,
Nov 27 2016
No one has reported any repros on NVIDIA or AMD at this point. Ken what GPU were you testing on in #5? Could be a tricky Intel bug. Adding Intel label provisionally.
,
Nov 27 2016
I have Nvidia and I have the bug
,
Nov 27 2016
OK, scratch that. Might be some chrome/canvas specific issue then.
,
Nov 27 2016
Also quentin.goinaud, can you upload a saved copy of Chrome's about:gpu on the affected machine?
,
Nov 28 2016
Looks like this may be a bug in DirectComposition in Windows. I can get it to flicker transparent even when I make the backbuffer opaque and then draw red to the backbuffer immediately before swap every time. It's possible Chrome is temporarily hiding the backbuffer or window, but I think I've narrowed down most cases where that could happen and they don't seem to be causing this.
,
Nov 29 2016
I think there actually is a bug in Chrome, where setting the icon of the window because audio stops or starts causes the window to temporarily be marked as not visible (it's complicated).
,
Nov 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b31f7c090c114097fc46ca120a3d0d221a238e88 commit b31f7c090c114097fc46ca120a3d0d221a238e88 Author: jbauman <jbauman@chromium.org> Date: Wed Nov 30 09:58:29 2016 Disable redraw lock when using DirectComposition. This can cause windows to flicker black when they're made invisible. It should also be unnecessary, as WS_CLIPCHILDREN should prevent DefWindowProc from modifying window contents in the area where Chrome is rendering. BUG= 667731 Review-Url: https://codereview.chromium.org/2536983002 Cr-Commit-Position: refs/heads/master@{#435203} [modify] https://crrev.com/b31f7c090c114097fc46ca120a3d0d221a238e88/ui/views/win/hwnd_message_handler.cc [modify] https://crrev.com/b31f7c090c114097fc46ca120a3d0d221a238e88/ui/views/win/hwnd_message_handler.h
,
Dec 2 2016
We can take this fix for M56.
,
Dec 8 2016
So far this seems stable enough for M56. If people want a workaround before then, they could try making sure their app is always playing audio (at least when in fullscreen). I know that's terrible for performance/etc. but it should work.
,
Dec 8 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5d94bf35db9e4bbf1fc7562992962bb651380521 commit 5d94bf35db9e4bbf1fc7562992962bb651380521 Author: John Bauman <jbauman@chromium.org> Date: Thu Dec 08 02:22:15 2016 Disable redraw lock when using DirectComposition. This can cause windows to flicker black when they're made invisible. It should also be unnecessary, as WS_CLIPCHILDREN should prevent DefWindowProc from modifying window contents in the area where Chrome is rendering. BUG= 667731 Review-Url: https://codereview.chromium.org/2536983002 Cr-Commit-Position: refs/heads/master@{#435203} (cherry picked from commit b31f7c090c114097fc46ca120a3d0d221a238e88) Review URL: https://codereview.chromium.org/2562613002 . Cr-Commit-Position: refs/branch-heads/2924@{#400} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/5d94bf35db9e4bbf1fc7562992962bb651380521/ui/views/win/hwnd_message_handler.cc [modify] https://crrev.com/5d94bf35db9e4bbf1fc7562992962bb651380521/ui/views/win/hwnd_message_handler.h
,
Dec 8 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by a...@scirra.com
, Nov 22 2016