9

Whenever I want to switch to a tab other than the one that is being rendered, Chrome hangs for about 2 seconds before rendering the new tab. This occurs whenever a new tab has to be showed, such as clicking the "New Tab" button, or closing the current tab.

Here's my version information:

Google Chrome 14.0.835.163 (Official Build 101024)

OS:Linux (Ubuntu 11.04)

WebKit 535.1 (branches/chromium/835@94713)

The only extension I use is AdBlock, and disabling it had no effect.

This has only been occurring to me since I updated to the most recent version of Chrome.

Any idea of what's going on?

Improve this question
6
  • Have you tried disabling the default "New Tab"-Page? You can do so with the extension "New Tab Redirect". Try changing it to about:blank. Does it make any difference?
    – Duijf
    Commented Sep 19, 2011 at 20:23
  • I'm not sure if I was clear. This happens even if I have two tabs open, say one on www.google.com, and another on www.youtube.com, and I want to switch from one to the other (also, the problem doesn't depend on the content of the tabs: I can have two tabs on about:version, and switching between them causes the delay).
    – Alex Dias
    Commented Sep 19, 2011 at 20:31
  • As far as I was able to see, there were no bug reports about this problem. Could it be a conflicting application?
    – Duijf
    Commented Sep 19, 2011 at 20:45
  • Perhaps, even though this occurs also when not much else is running. Just before I updated Chrome (which caused the issue), I installed gcc-4.4, g++-4.4 and their dependencies (giving me two versions of both gcc and g++: 4.4 and 4.5). However, doing this on a live cd didn't cause any problems, so I guess the two installed versions of gcc and g++ aren't what's causing the problem. Also, I just installed Chromium, and the problem does not exist there.
    – Alex Dias
    Commented Sep 19, 2011 at 20:52
  • Interestingly, this started to happen to me just now when updating to a new version on 2012-04-13. It now happens with stable, unstable and beta builds. I see many other intermittent bug reports on this subject, but no real answers. I'll continue investigations.
    – Daniel Andersson
    Commented Apr 13, 2012 at 14:43

3 Answers 3

Reset to default
4

I encountered a similiar behaviour with tabs that weren't (pre)rendered in the background anymore and sometimes not even when brought up front. Fortunately I remembered having activated the GPU-Compositing in about:flags (which worked fine until one or two weeks ago). Disabeling it again solved this issue.

Improve this answer
1
  • Weird, this REALLY speeded up the rendering process on Chrome.
    – mowwwalker
    Commented Jun 22, 2013 at 6:40
1

I just now also tracked down another issue with libcairo2 currently in Debian Sid. See Debian bug #682308.

With cairo-1.12.0, there is a regression bug causing tab switching and new tabs opening in Google Chrome and Chromium to stall significantly and spike xorg CPU usage.

Three different workarounds are mentioned in the bug report, awaiting an upstream fix:

  • Running

    nvidia-settings -a InitialPixmapPlacement=0
  • Pinning package to version 1.10.2-7.
  • Building recent libcairo with patch changing src/cairo-xlib-display.c by setting display->buggy_gradients to be always TRUE (from a post on the Debian forums) (consider pinning it too, in case future libcairo2 updates still lack the fix).

This finally solved my issues.

UPDATE

This is supposedly fixed in Nvidia driver 304.30 released 2012-07-30. From the changelog (not yet online, due to NvNews recently being hacked recently and Nvidia's own page not hosting the changelog specifically, but it is inside the binary package they provide):

- Fixed a problem where RENDER Glyphs operations would exhibit severe
  performance issues in certain cases, such as when used with gradients
  by Cairo and Chromium.

UPDATE 2

...and now this driver version has hit Debian Unstable, at least.

Improve this answer
0

Since Google Chrome's tabs are trapezoidal, they use a specific function in the driver called "trapezoidal acceleration", which is supported in hardware by newer Nvidia circuits.

On older circuits without this support, there was a bug that showed up in combination with upgrades to X.org 1.11 (where I guess X.org started supporting direct trapezoidal rendering) which made trapezoidal rendering much slower than it should have to be (much slower than it was with earlier driver/X.org server combinations). I run a GeForce 9400 which is one of the affected circuits.

The Debian bug report.

The Nvidia driver fix announcement in 290.03.

Personally I had this issue with even newer Nvidia versions (295.40), which persisted through a restart, but for some reason just launching nvidia-settings fixed it.

Chrome is still a lot slower than e.g. Opera in tab switching and creation on my machine, but it no longer induces delays of several seconds. From all I can tell, it is back to the speed it was before the bug introduction.

EDIT: This information is just as true as before, but there was an additional bug that affected all Nvidia cards. See my other answer for more information.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .