Issue metadata
Sign in to add a comment
|
Slow/laggy Chrome Browser performance |
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36 Steps to reproduce the problem: 1. Load Chrome in the Unity window manager, ensuring Chrome and Unity are using GPU acceleration. 2. Load a page in Chrome that is constantly updating the screen--an animated GIF works well, like http://giphy.com/gifs/gonwild-esseract-j0EcojD7hIvuM 3. Perform other activities in Chrome or in other applications that involve redraws. For example, bring a large window to the foreground, and then another large window to the foreground. There's also a more noticeable lag in text entry (though more subtle). Resizing windows, especially Chrome windows, may also show the increased lag of the graphics subsystem. 3. Run Chrome with --disable-gpu, or under another window manager, like XFCE and these issues are not present. What is the expected behavior? Expect that Chrome behaves at least as well using GPU acceleration as when it is not. What went wrong? System is less responsive and feels much slower. Did this work before? No Chrome version: 50.0.2661.75 Channel: stable OS Version: Flash Version: Shockwave Flash 21.0 r0 My hardware is a very modern desktop (HP Z440) with a Quadro K620 GPU (2GB RAM). The card has >1GB free FB RAM when this is happening. I don't see any high GPU memory usage or high idle wakeups in the Chrome Task Manager. Note that this issue is easier to see on a high resolution screen, as things like bringing a large window to the foreground are more intensive operations.
,
Apr 17 2016
Oh, just go to "Task Manager", end the following tasks called 'Hotword Triggring' or just simply end the "GPU Process", exit task manager and refresh the page. (The Difference is 100%).
,
Jun 3 2016
,
Apr 4 2017
Just to clarify, you're seeing the bug when you have multiple Chrome windows open and one of them has animating content, correct? This is a known side-effect of having multiple GLX surfaces share a single thread for issuing swap buffers. On Windows we have a workaround where we set swap internal to 0 when we have multiple windows. We should deploy this workaround to Linux as well.
,
Apr 4 2017
,
Apr 4 2017
same root cause as bug 528803 ?
,
Apr 4 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by sunn...@chromium.org
, Apr 15 2016