New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 303293 link

Starred by 14 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2013
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Switching tabs causes the first tab to freeze up, even after pressing the reload button

Reported by devans...@gmail.com, Oct 2 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open a tab, we'll call it "Tab A"
2. On Tab A, load any webpage you like.
3. Once the page on Tab A is loaded, open a new tab, "Tab B".
4. On Tab B, load any webpage you like.
5. Switch back to Tab A.

What is the expected behavior?
I expect all of my tabs to function correctly, even if I switch between them.

What went wrong?
After following all 5 of the steps I have given you, Tab A, at this point, should be frozen. Hovering your mouse over the page elements doesn't cause a cursor change, the reload button does nothing, and the tab is pretty much useless.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? N/A 

Did this work before? Yes It seems as if the problem began only once I updated to Chrome 30.

Does this work in other browsers? Yes Tabs function correctly in all browsers aside from Chrome.

Chrome version: 30.0.1599.66  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 11.8 r800

This has caused my Chrome experience to degrade to such a point where I've been forced to use Firefox. I would NEVER do something like that unless I was forced to, and unfortunately, I was.

I really want to get back to Chrome immediately, so please try and solve this for me as soon as you can.

Thanks!
 
Cc: wiltzius@chromium.org vangelis@chromium.org
Can you try a few things for us?

1. Try starting Chrome with a clean user profile and no extensions and see if the problem still happens
2. Try running chrome Canary and see if you still have this problem
3. Send us the contents of your about:gpu page?
1. Problem still occurs.

2. Chrome Canary is working great, seems faster than the Stable release even when it worked correctly. Might just be how my perception of browser speed is being distorted by Firefox though. But the bug is no longer there in Canary.

3. Attached.
gpu.htm
79.0 KB View Download
I think I figured out the problem.

I was going through my chrome://flags page and comparing the differences between my Stable and my Canary browsers, and enabling onto my Canary browser the flags that I set on my Stable. When I enabled Disable GPU Vsync, it caused the bug to appear in the Canary browser. I am almost sure that was the root of my problem.

However, now that I'm using this Canary release, I'm starting to like it. Would it be a terrible idea to use it as my common, everyday browser and just uninstall my Stable version? Canary doesn't seem to be as buggy as the webpage you download it from makes it out to be.

Comment 5 Deleted

Comment 6 by kareng@google.com, Oct 2 2013

devansnow, canary gets updated every day and doesn't go through a QA process, it's use-it-at-your-own-risk. :) However, it runs side by side with other Chrome installations so you can keep both Stable and Canary and use both.
Oh, okay, I see. Sounds like a hole I don't want to dig myself too deep into at the moment, ha.

Anyways, is there any reason why disabling GPU vsync would cause my tabs to freeze? It never happened until the Stable channel got updated to 30. Something must've been changed within the code of the feature, hm? Or some sort of conflict must have arisen? Do you think the developers will attempt to fix a feature as tucked away as this?
Cc: melodychu@chromium.org
Cc: jbau...@chromium.org briander...@chromium.org
@devansnow - could you flip back to the broken Stable Chrome and record a tracing run and attach that to this bug?  Directions are here: http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs.

+cc brian/john/vangelis to see if the vsync thing makes sense
I can repro on canary
Hmm, it's really hard to record a trace when the tracing tab is frozen.
Like @jamesr said, the tracing tab freezes.
@devansnow - did you have "Disable GPU Vsync" enabled in your Stable build when you first noticed that it was broken?  If so, can you turn that off and see if your Stable channel recovers?  We broke that flag recently and it's still broken.
I had that flag enabled before the problem showed up, yes.

Like I said earlier, I was doing some fooling around with the flags trying to figure out the problem an hour or two ago. Made a list of flags I have set that aren't the default, then I set everything back to default. I went through one-by-one following my list setting flags back to how I had them, and when I enabled "Disable GPU Vsync", the problem popped up again. That's how I came to the conclusion that the flag was the source of my troubles.

This problem did not exist before the new Stable update yesterday, version 30. I have had the flag enabled for a while now, so the new update must have had something to do with it, I assume.
I have the same problem.

With Chrome stable, when I disable the vsync some tabs just froze. But the browser it's still responsive.
I've tried the beta, and they have the same issue. I have three computers with different hw configurations and the same issue.
The problem is that Chrome with vsync seems so laggy. 

The only way that vsync off work - is with hw acceleration off from Chrome's setting menu. But unfortunate this also disables flash hw aceleration.

Any solution? With Chrome 29 everything was ok.

----------------------------------------------------
Bug appears using Windows 7 x64 and Windows 8 x64
under a NVIDIA GTS 450, Ati 4250 and an Intel HD 4000.
with fresh install and latest available drivers for each one.

Labels: Merge-Requested M-30
Status: Started
We'll need to merge https://codereview.chromium.org/25814003/ back into the M30/M31 branches (that removes the Disable GPU Vsync about:flags entry) and then fix --disable-gpu-vsync on trunk so it works going forward.
Cc: karen@chromium.org lafo...@chromium.org
+Karen for m30 approval, +Anthony for m31

Comment 18 by kareng@google.com, Oct 3 2013

Labels: -Merge-Requested Merge-Approved
https://codereview.chromium.org/25814003/ apporved for m30.
Project Member

Comment 19 by bugdroid1@chromium.org, Oct 3 2013

------------------------------------------------------------------------
r226626 | jamesr@chromium.org | 2013-10-03T00:16:15.362116Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/about_flags.cc?r1=226626&r2=226625&pathrev=226626

Remove disable-gpu-vsync about:flags entry

This entry completely breaks Chrome and has for a while.

BUG= 303293 
R=jbauman@chromium.org

Review URL: https://codereview.chromium.org/25814003
------------------------------------------------------------------------
Project Member

Comment 20 by bugdroid1@chromium.org, Oct 3 2013

Labels: -Merge-Approved merge-merged-1599_59
------------------------------------------------------------------------
r226627 | jamesr@chromium.org | 2013-10-03T00:19:44.410721Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599_59/src/chrome/browser/about_flags.cc?r1=226627&r2=226626&pathrev=226627

Merge 226626 "Remove disable-gpu-vsync about:flags entry"

> Remove disable-gpu-vsync about:flags entry
> 
> This entry completely breaks Chrome and has for a while.
> 
> BUG= 303293 
> R=jbauman@chromium.org
> 
> Review URL: https://codereview.chromium.org/25814003

TBR=jamesr@chromium.org

Review URL: https://codereview.chromium.org/25607008
------------------------------------------------------------------------
While this thread is still active, may I ask what this merge means? It looks like the Disable GPU Vsync flag is going to be removed from the about://flags page completely, is that correct? Or is it going to be fixed instead of removed?

Also, will the change be immediate or will we need to wait about a month for it to cycle through all of the other channels (Canary, Dev, etc)?
Project Member

Comment 22 by bugdroid1@chromium.org, Oct 3 2013

Labels: merge-merged-1599
------------------------------------------------------------------------
r226628 | jamesr@chromium.org | 2013-10-03T00:20:54.995525Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/chrome/browser/about_flags.cc?r1=226628&r2=226627&pathrev=226628

Merge 226626 "Remove disable-gpu-vsync about:flags entry"

> Remove disable-gpu-vsync about:flags entry
> 
> This entry completely breaks Chrome and has for a while.
> 
> BUG= 303293 
> R=jbauman@chromium.org
> 
> Review URL: https://codereview.chromium.org/25814003

TBR=jamesr@chromium.org

Review URL: https://codereview.chromium.org/25727007
------------------------------------------------------------------------
I have the same question as #21.

Personally it's a nightmare to use Chrome with vsync on. Scrolling it's very laggy with my monitor. 
With my old CRT monitor it's fine because of the high refresh rate.

Comment 24 by kareng@google.com, Oct 3 2013

For 30, for now, it will be removed, we are simultaneously working on a fix. 
Understood. Thank you.
If you are having bad framerate issues with vsync enabled, can you please attach a trace? Most monitors today should refresh at 60Hz . 
James, shouldn't we in addition disable force-disable the disable-gpu-vsync flag for the folks who already have it in their user-profile? 
 
I see. Glad to see a bug report system that actually gets acknowledgement from the devs. Thanks for the help!
Cc: enne@chromium.org
I bisected the --disable-gpu-vsync regression to enne's r214314 / https://chromiumcodereview.appspot.com/19106007 "cc: Allow the main thread to cancel commits"

enne: do we understand why, and if the reason could cause problems outside of when vsync is disabled?
> James, shouldn't we in addition disable force-disable the disable-gpu-vsync flag for the folks who already have it in their user-profile? 

That's what my patch does.  If the entry is not in about_flags.cc, the bit in the user profile won't map to anything.
Cc: jam...@chromium.org
Ah, ok, thanks! I thought the user profile stored the flag directly. 

Comment 33 by Deleted ...@, Oct 3 2013

I had the same problem on Chrome 30, in chrome://flags/, I pushed "reset all to default" and after relaunch, it's back to normal :D
btw, I use to activate GPU accel flags and other GPU experiments (I'm a webgl fan).
Sorry for the delay. My monitor is a Benq GW2250HM, connected with DVI. The refresh rate is 60Hz.
The problem comes with webs like Google Maps, or any web page that have 'moving' elements and animation. Because of the VSync everything is laggy, it doesn't fallow the cursor movement.

Other example is scrolling by dragging the scroll bars. They always fall behind the cursor, like it can't keep it up. This gives a general feeling of slowness.
A lot of people that I work with are telling me that lately Chrome is slow, and it's because of this 'problem'. With VSync of everything works much better, no input lag.

Today I figured out a workaround to work without VSync. I keep HW acceleration enabled from the settings, then I disable it from chrome://flags.
This way I can keep the flash gpu acceleration and Chrome works great. I don't care about some ms in benchmarks, but it feels much faster this way.

I work in a very dynamic environment, constantly searching for data - copy/pasting, processing and it's very important to have responsive computer.

----------------
Sorry for my English,
it's not my mother tongue.

Comment 35 by enne@chromium.org, Oct 3 2013

piman, re: comment #29: Thanks for the bisect info.

For background, the "aborting commits" patch caused a few bugs that required follow-up, which all made it into m30.
https://codereview.chromium.org/21567003 (video layers)
https://codereview.chromium.org/22314002 (IO surface layers)
https://codereview.chromium.org/22469002 (tab switching)

In particular, the third one seems the most similar to what might be going on here, although why vsync would affect this is a mystery.

A few questions would be:
-What's the CanDraw() state of the tree?
-Is it trying to redraw, but the embedder isn't setting damage so we early out without drawing?
-Does invalidating the page somehow cause it to stop freezing?

Comment 36 by enne@chromium.org, Oct 3 2013

Owner: enne@chromium.org
Status: Assigned
@enne: --disable-gpu-vsync is still broken on ToT, so it shouldn't matter a whole lot whether a given patch made it into m30.

Re comment #34: I think you're seeing  bug 262437 .
@gyorke if you're realy seeing laggy animations without vsync, it would help to have a trace of a bad example. Instructions for how to record a trace are here:

http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
Laggy with vsync, without vync everything works fine.

Or at least with with Chrome 29, with 30 I can't have vsync off for more than 5 seconds because it freezes.

I don't think is  bug 262437 , because I'm having this problem since way (several months) back. I was able to solve this by disabling vsync.
Project Member

Comment 40 by bugdroid1@chromium.org, Oct 3 2013

Labels: merge-merged-1650
------------------------------------------------------------------------
r226840 | jamesr@chromium.org | 2013-10-03T20:53:34.990171Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1650/src/chrome/browser/about_flags.cc?r1=226840&r2=226839&pathrev=226840

Merge 226626 "Remove disable-gpu-vsync about:flags entry"

> Remove disable-gpu-vsync about:flags entry
> 
> This entry completely breaks Chrome and has for a while.
> 
> BUG= 303293 
> R=jbauman@chromium.org
> 
> Review URL: https://codereview.chromium.org/25814003

TBR=jamesr@chromium.org

Review URL: https://codereview.chromium.org/25863004
------------------------------------------------------------------------

Comment 41 by Deleted ...@, Oct 3 2013

I just upgraded to 30.0.1599.69 ... I still have the issue.  Nothing helps, chrome is completely unusable.
@gyorke.marian - could you please record a trace of a laggy web page and file a new bug?

@kvacola - could you please attach the full output of "about:version" and "about:gpu" to this bug?  Thanks!
I updated to the latest 30.0.1599.69m and everything works.

I still have kinda lagg, but I'm pretty sure it's because of how vsync works. But it's way better than before, it's not bothering anymore.
Scrolling and animations, Google Maps way it's smoother. 

Everything with a clean installation and all by default. Finally I don't have that feeling that I have to push Chrome to move.

I'll keep testing and if problem appears, I'll file new bug. 

Thank you all!
where is gpu vsync menu now with 30.0.1599.69 version? cannot find it?
It's gone. They removed it until the bug it's fixed.
 Issue 303844  has been merged into this issue.
Project Member

Comment 47 by bugdroid1@chromium.org, Oct 4 2013

------------------------------------------------------------------------
r227060 | enne@chromium.org | 2013-10-04T19:49:18.139449Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/trees/layer_tree_host_unittest.cc?r1=227060&r2=227059&pathrev=227060
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/scheduler.cc?r1=227060&r2=227059&pathrev=227060
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/scheduler_state_machine.cc?r1=227060&r2=227059&pathrev=227060
   M http://src.chromium.org/viewvc/chrome/trunk/src/cc/scheduler/scheduler_state_machine.h?r1=227060&r2=227059&pathrev=227060

cc: Fix disabled vsync state freezing

Previously, when vsync was disabled the scheduler state machine would
never proactively request a new begin frame message.  This logic was
tightly coupled to commits not being aborted and causing a redraw,
incrementing the frame number, and allowing a number of the "only once
per frame" logic in the state machine to proceed.

Instead, treat disabled vsync like the synchronous compositor.  In both
cases, it's undesirable to proactively request a begin frame.  For the
synchronous compositor, this is because every begin frame results in a
draw.  For the unthrottled disabled vsync case, this is because if the
compositor can't draw it will get into a tight loop of continuing to
request new begin frames.  By lumping it with the synchronous compositor
logic, it will periodically poll to see if it needs to start a new frame
rather than freezing forever.

R=brianderson@chromium.org
BUG= 303293 

Review URL: https://codereview.chromium.org/25494009
------------------------------------------------------------------------
The fix in #47 will not apply cleanly to M30, but do we want to merge it to M31?
Looks like jamesr's patch removing the disable-vsync flag was merged to the M31 (1650) branch. I don't think it's worth merging the fix at this point.

Comment 50 by Deleted ...@, Oct 23 2013

Regarding #47 & #49 - will the fix get pushed out soon? I'm using 30.0.1599.101 and Chrome causes my mac to freeze multiple times in a day. It's to a point that Chrome is not usable. Thank you.
#50: The fix has been out in Chrome 30 for a while now so what you're experiencing is a different issue. Can you please open a new bug with a detailed description of what you're observing. 

Comment 52 by enne@chromium.org, Oct 31 2013

Status: Fixed
Excuse me for a late and off topic question.
Is the root fix to this issue, r227060 meaning that Chrome now works in different ways with and without VSync?
Supposing that is the case, how will the mechanism interacts with NVIDIA's adaptive VSync, which dynamically turns VSync on and off depending on real-time frame rate?

If my Chrome for some reason cannot stably maintain 60 fps which is likely to threaten adaptive VSync randomly switching VSync off, would it be better not to use adaptive VSync with Chrome in any sense?

Thanks in advance.

Sign in to add a comment