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 16 users
Status: Fixed
Owner:
not on Chrome anymore
Closed: May 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment
Very flickery on resize Chrome 32 (hardware acceleration)
Project Member Reported by scottmg@chromium.org, Oct 9 2013 Back to list
Post http://src.chromium.org/viewvc/chrome?view=revision&revision=227583

resizing is very flickery on Win8 at least. Black flashes for all of the UI area on every paint. More visible in classic mode because there's more UI drawn. The content area seems fine.

Additionally, in classic frame, the top few pixels of the frame are corrupted somehow (not painted? wrong colour? not sure)

Reverting 227583 fixes the top few pixels corruption.

Reverting or --ui-disable-partial-swap fixes the black flash.

Might be OK to ship for one Canary to see if there's other problems I guess?
 
Works fine on Win 7. I think the issue is that the GPU process swaps, the window resizes, then GPU process does a partial swap, and Windows clears the part of the window that's outside the swapped area.
Possible solutions:
1) Make a child window that resized synchronously.
2) Avoid partial swaps when resizing (probably also a good idea for keeping the framerate up while resizing). See also  issue 298647 .
3) Rubberbanding.
Labels: m-32 ReleaseBlock-Stable
Status: Assigned
Well we need resolution one way or another for M32, but I don't have any opinions on what the right thing to do is.
Cc: geoffl...@chromium.org jmad...@chromium.org shannonwoods@chromium.org
Is there anything we could do in ANGLE to avoid this issue where the rest of the window flickers to black on PostSubBuffers after resize? I suspect there's nothing that would conform to the EGL spec precisely, but maybe expanding the blit to cover the entire backbuffer would be close enough.
FWIW, I don't see this on Win81 in a 1 GPU machine with a Quadro 600, I only get it on the machine that has the Quadro + the old one (9500 or something).
Actually, expanding the blit doesn't seem to work, as the last swapbuffers may have resized the window afterwards, destroying everything. I can't get anything to fix this sort of issue (though I am attempting to repro it by doing DwmGetCompositionTimingInfo on the window, which may be different from what Scott's getting). However, it does seem pretty rare, so maybe it shouldn't block the release. We already have issues like this when resizing a themed window.
How does this relate to  issue 120904 ? Amusingly Al suggested Aura would solve it.
Hard to say. I think the exact cause is somewhat different, though it's hard to tell exactly what's going on in either case.
Cc: capn@chromium.org
Comment 9 by capn@chromium.org, Nov 7 2013
Have you tried inserting Sleep() before/after resize, before/after blit, etc. to locate where this is caused?
jbauman,
What hardware are you able to repro this on? Is it only dual GPU machines?

jmadill and I are trying on a win8 laptop and get black boxes in the space created by resizing but there doesn't appear to be flickering in the areas that aren't moved.
Scott was able to cause this on a dual-GPU win8 machine.

I haven't been able to reproduce the exact initial conditions, but I found that if I ever do DwmGetCompositionTimingInfo on the hwnd that is being presented to (on Win7) , then that causes the window to switch to a mode where this happens.
I patched the compositor not to do partial swaps for 30ms after a resize, but it still seemed to have the problem on the initial resize. So if there's a race condition it'll have to be fixed somewhere in the GPU process.
Comment 13 by kareng@google.com, Nov 7 2013
Labels: notnov18
I was able to repro the flicker using --disable-gpu-sandbox and added a call to DwmGetCompositionTimingInfo as John suggested. The flicker happens in D3D9 but not D3D11 for me. Because VS graphics debugging doesn't work for D3D9, and we can't easily check the D3D9 debug runtime for warnings and errors, it's hard to tell what's causing the flicker.

I noticed disabling PostSubBuffer fixed the problem, so we can land an ANGLE patch to disable PostSubBuffer for D3D9 -- I suspect (though not tested) even when it works presenting a subsection of the frame isn't a big performance win for desktop cards.
I put up an ANGLE-side CL at https://codereview.appspot.com/23610044/ to disable PostSubBufferNV on D3D9 (it isn't supported in D3D11 either, currently)
Comment 16 by cpu@chromium.org, Nov 8 2013
Note this only happens for some machines. Afaik in my proximity it only happens for Scott's dual monitor + quadro and John's machine.


Total shot in the dark here, but can you see if the flicker with direct presentation path happens with the patch that is uploaded here: 

https://codereview.chromium.org/59043012/

The 1-pixel hack is responsible for so many weird things, and anecdotally I seem to notice less flickering with my local build than I did a few days ago, so maybe it's related?
No, getting rid of the 1-pixel hack doesn't seem to fix it for me.

I think the bigger win with PostSubBuffer is that the compositor doesn't have to redraw the entire frame, but can just draw the part that changed (we in theory could do that with SwapBuffers on ANGLE, but there's no way to guarantee that on an arbitrary EGL implementation, so it's not enabled). I'm not sure if it's worth it to disable that, given that only 1 person has experienced a problem.
Comment 19 Deleted
Labels: Cr-Internals-GPU-ANGLE
Cc: vangelis@chromium.org
Is there realistically anything we can do about this at this point?
Maybe just alert ConOps and monitor when we go to stable to see if people complain?
Yeah, it doesn't seem like there are any good options, so it would probably just be best to wait and see.
Is there anything I can do to help? But I agree, if it's really just me, then meh.
Comment 25 by cpu@chromium.org, Dec 10 2013
Labels: Hotlist-ConOps
Summary: Very flickery on resize Chrome 32 (hardware acceleration) (was: Very flickery on resize with direct presentation path)
Haven't seen anybody from the 2% complaining at least in bug form. Let's bring this to ConOps attention.

-Adding Hotlist-ConOps (not sure it is the right thing)
-Simplifying the title

Scott is it possible to capture a move of the thing happening? so people are clear given that the bug has so many things in it?


It's less flickery with the video capture running because the fps is very low, but you can see where the blackouts are happening at least.
flicker.mp4
2.3 MB Download
It's less flickery with the video capture running because the fps is very low, but you can see where the blackouts are happening at least.
flicker.mp4
2.3 MB Download
So weird that it doesn't happen everywhere; I have the default Win8 theme too and don't see it. Scott have you seen this only on Nvidia cards?
Meanwhile I will tell ConOps about htis.
Yes, but I only have a sample set of 3 (one NV machine where it happens,
one where it doesn't, and one Intel where it doesn't)
Labels: -ReleaseBlock-Stable
Comment 32 by than...@gmail.com, Feb 10 2014
Same problem here. 

I'm using Chrome 32.0.1700.107 and Canary 34.0.1827.0 side by side on Windows 7 x64.
This issue ONLY happens in Chrome & Canary. No other application has this kind of issue in any way.

Chromium 26 does NOT have this issue, so either it due to a feature that in Chrome and not in Chromium, other something got messed up between version 26 and 32.

I've already tried resetting the things on chrome://flags, and I can confirm it makes no difference whether the dev tools are open or not.
Comment 33 by capn@chromium.org, Feb 11 2014
Cc: nduca@chromium.org
I recently noticed that ANGLE checks whether the swap chain needs resizing on two occasions: after an eglSwapBuffers, and when the window receives the WM_SIZE event (https://codereview.appspot.com/3122041). The latter does not make sense to me (I wasn't involved in writing or reviewing the code at the time). When a resize happens in the middle of a frame, we should simply continue to draw, present the result in the window (which requires stretching it to the right size - which D3D takes care of automatically), and then recreate the swap chain for the new window size.

Recreating the swap chain as soon as a WM_SIZE event is received may cause some sort of flicker. That said, I can't reproduce this. Would anyone who can reproduce it be willing to test a custom ANGLE build, or can you set it up so I can RDP/Chromote into it?
ANGLE doesn't resize the window in Chrome on WM_SIZE because the window it's drawing into was created by another process/thread (GetWindowThreadProcessId returns different IDs) and can't be subclassed. However, there are issues because the window may be resized at a different time than the compositor was expecting (because they're on different threads), so a partial swap will happen just after the window was resized.
Comment 35 by capn@chromium.org, Feb 11 2014
Indeed the window never gets subclassed. I wonder if we should keep that code at all then.

Nat, do you recall why it was added exactly? https://codereview.appspot.com/3122041 doesn't specify what kind of corruption was observed or how to replicate it.
Comment 36 by nduca@chromium.org, Feb 11 2014
The issue to consider is when there's a resize of the hwnd on the main browser thread when the angle process is mid-frame. That review has some context linked in its previous review, https://codereview.appspot.com/3038042/#msg9  ... if I recall, the issue was that angle [used to, currently?] reads the hwnd size itself on every draws and automatically resized the framebuffer: https://codereview.appspot.com/3038042/diff/15001/src/libGLESv2/Context.cpp

Comment 37 by capn@chromium.org, Feb 11 2014
Is this because the browser process uses absolute coordinates and would issue draw commands assuming the new window size, while the 'GPU' process still uses the previous window size until the next swap?

I think there can still be a delay between the resize and when the draw calls are received. So the proper solution seems to be to keep the old swap chain and let Windows stretch it to the right size on a buffer swap. Only after that a new swap chain is created. This requires that the browser process scales the coordinates for all the draw calls between a resize and the next buffer swap.

Is that currently being done? As John noted the window does not get subclassed any more so the WM_SIZE isn't received.
Comment 38 by than...@gmail.com, Feb 17 2014
Instead of contemplating on a gazllion possible causes, you could also just compare the code responsible with Chromium 26. It worked absolutely fine in that release.
Comment 39 by cpu@chromium.org, Feb 18 2014
thany81, Sure but the problem is that the code does not resemble at all that of chrome 26. It was a drastic engine replacement. 

nicolas, nat, I assume this problem will go away if we do synchronous paint during resize. My pet theory is that DWM gets notified when you do the BeginPaint/EndPaint so it can upload the texture and compose it with the frame but we never paint there; we post a message and later on the GPU process comes along a presents from the other process.

Comment 40 by than...@gmail.com, Feb 19 2014
@cpu The engine is not the problem, the problem is in the application around it.

Of course, comparing 32 and 26 would result in a hugeass diff, but what if you limit yourself to the stuff that takes care of the chrome around the engine? Not to mention, this is *exactly* what source control is for.
Comment 41 by cpu@chromium.org, Feb 19 2014
let me be more explicit. the UI was being drawn with GDI and now its being drawn with DirectX. If you look at the two APIs you'll see they are very different.
Comment 42 by than...@gmail.com, Feb 25 2014
Not sure if drawing the UI with DirectX is "the"way to go, really. Windows draws all of its window chromes with Aero effect and everything using the DWM. Not sure if that ultimately used DirectX or OpenGL or what have you, but it certainly doesn't use DirectX straight away.

I may be oversimplifying this, but why not just do what Windows does? It works fine the way Windows does these things...
Comment 43 by Deleted ...@, Apr 23 2014
I experience this issue on Chrome 34 when using both the discrete GPU (AMD Radeon) and the integrated Intel GPU.  When using just the Radeon, no issue.  When having one monitor plugged into the Radeon and one plugged into the Intel GPU on the motherboard, I experience the black flashes on the Chrome UI (address bar and bookmark bar) when resizing, but not on the website content.  As was stated earlier, no other Windows applications exhibit this, so I tend to think it is a Chrome problem and not an AMD driver problem.  Why does the team feel there are no good options to resolve this?
Comment 44 by than...@gmail.com, Apr 23 2014
In any case, DirectX is not meant for drawing window chromes. It is meant for games (and websites, apparently).

The GUI oughta be drawn using either the GDI or the DWM. Just like all other applications do, including all other browsers. Windows already handles things like this perfectly fine and smooth. No need to reinvent a square wheel.
Labels: -m-32 m-36
Status: Fixed
This should be fixed by r270206
Comment 46 by Deleted ...@, Jun 11 2014
I still experience this problem 
Linux Mint 17
Chrome Version 35.0.1916.153
Nvidia drivers 331
Comment 47 by than...@gmail.com, Jun 12 2014
Well, the *flickering* is gone for me in Canary 37.0.2044.2, but resizing the window is still very very slow, just as slow as when it did flicker.

My system is *more* than capable of resizing a window at 60fps, and it doesn't matter which website or chrome-page is showing, nor how many tab are open. Even when a single tab is open, showing chrome://chrome/ resizing the window is incredibly sluggish.
Comment 48 by than...@gmail.com, Jun 12 2014
And that's still on Windows 7 x64 SP1, nVidia drivers 9.18.13.3523, ForceWare version 335.23, and all else is up-to-date. Hardware is an i7-4770K with 16GB memory (81% free, atm) and dual GeFore GTX760's in SLI mode, connected with three FHD monitors.

I "think" this system should be capable of smoothly resizing a window.
I'm still affected by this bug, have been for awhile.

Version 35.0.1916.153 Debian jessie/sid (274914)
nVidia 340.24

Any idea's?
Comment 50 by than...@gmail.com, Jul 31 2014
I'm now also having this issue on my other pc - a laptop with Windows 7 x64, Intel HD Graphics 4000, driver version 10.18.10.3621 (as it says in the device manager), and everything else is up-to-date. My Chrome is at version 36.0.1985.125. Canary is also having this issue, at it is at version 38.0.2108.0.

Also, 100% CPU (on one core) while resizing, so not only does it perform poorly, it's also eating my battery alive.
I still ahve the issue, not fixed for me, and on many computers I tried.

Data exported	3/5/2015 23:48:18
Chrome version	Chrome/44.0.2383.0
Operating system	Linux 3.13.0-37-generic
Software rendering list version	10.4
Driver bug list version	7.22
ANGLE commit id	ad0a486b9433
2D graphics backend	Skia
Comment 52 by Deleted ...@, Jul 20 2015
Version 43.0.2357.134 m - still bugging me
This is still happening to me on Linux with intel drivers:

Data exported	8/2/2015, 8:42:10 AM
Chrome version	Chrome/44.0.2403.125
Operating system	Linux 4.1.3-1-ARCH
Software rendering list version	0
Driver bug list version	8.19
ANGLE commit id	fa9744b09e24
2D graphics backend	Skia
Command Line Args	--ui-disable-partial-swap --flag-switches-begin --ignore-gpu-blacklist --flag-switches-end
Driver Information
Initialization time	52
Sandboxed	true
GPU0	VENDOR = 0x8086, DEVICE= 0x1616
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	10.6.3
Driver date	
Pixel shader version	1.30
Vertex shader version	1.30
Max. MSAA samples	8
Machine model name	
Machine model version	
GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
GL_VERSION	3.0 Mesa 10.6.3

Sign in to add a comment