Google Chrome se bloque brièvement avant d'afficher un nouvel onglet

Chaque fois que je souhaite basculer vers un onglet autre que celui en cours de rendu, Chrome se bloque pendant environ 2 secondes avant de rendre le nouvel onglet. Cela se produit chaque fois qu'un nouvel onglet doit être affiché, comme cliquer sur le bouton "Nouvel onglet" ou fermer l'onglet actuel.

Voici mes informations de version:

Google Chrome 14.0.835.163 (version officielle 101024)

Système d'exploitation: Linux (Ubuntu 11.04)

WebKit 535.1 (branches / chrome / 835 @ 94713)

La seule extension que j'utilise est AdBlock, et sa désactivation n'a eu aucun effet.

Cela ne m'arrive que depuis la mise à jour vers la version la plus récente de Chrome.

Une idée de ce qui se passe?

— Alex Dias
source

Avez-vous essayé de désactiver la page "Nouvel onglet" par défaut? Vous pouvez le faire avec l'extension "New Tab Redirect" . Essayez de le changer en about:blank. Cela fait-il une différence?

— Duijf

Je ne suis pas sûr d'avoir été clair. Cela se produit même si j'ai deux onglets ouverts, disons un sur www.google.com et un autre sur www.youtube.com, et je veux passer de l'un à l'autre (également, le problème ne dépend pas du contenu des onglets: je peux avoir deux onglets sur about: version, et le basculement entre eux provoque le retard).

— Alex Dias

Autant que j'ai pu voir, il n'y avait aucun rapport de bogue sur ce problème. Serait-ce une application conflictuelle?

— Duijf

Peut-être, même si cela se produit également lorsque rien d'autre n'est en cours d'exécution. Juste avant de mettre à jour Chrome (ce qui a causé le problème), j'ai installé gcc-4.4, g ++ - 4.4 et leurs dépendances (me donnant deux versions de gcc et g ++: 4.4 et 4.5). Cependant, faire cela sur un cd live n'a pas posé de problème, donc je suppose que les deux versions installées de gcc et g ++ ne sont pas à l'origine du problème. De plus, je viens d'installer Chromium et le problème n'existe pas là-bas.

— Alex Dias

Fait intéressant, cela a commencé à m'arriver tout à l'heure lors de la mise à jour vers une nouvelle version le 2012-04-13. Cela se produit maintenant avec les versions stables, instables et bêta. Je vois de nombreux autres rapports de bugs intermittents à ce sujet, mais pas de vraies réponses. Je vais continuer les investigations.

— Daniel Andersson

Réponses:

J'ai rencontré un comportement similaire avec des onglets qui n'étaient plus (pré) rendus en arrière-plan et parfois même pas lorsqu'ils étaient affichés. Heureusement, je me souvenais d'avoir activé le GPU-Compositing dans about: flags (qui fonctionnait bien jusqu'à il y a une ou deux semaines). Le désétiqueter à nouveau a résolu ce problème.

— Maximilian Jänicke
source

Bizarre, cela a vraiment accéléré le processus de rendu sur Chrome.

— mowwwalker

Je viens de retrouver un autre problème avec libcairo2actuellement dans Debian Sid. Voir le bogue Debian # 682308 .

Avec cairo-1.12.0, il y a un bug de régression qui fait que le changement d'onglet et l'ouverture de nouveaux onglets dans Google Chrome et Chromium bloquent considérablement et augmentent xorgl'utilisation du processeur.

Trois solutions de contournement différentes sont mentionnées dans le rapport de bogue, en attendant une correction en amont:

Fonctionnement

nvidia-settings -a InitialPixmapPlacement=0

Épingler le package à la version 1.10.2-7.
Construction récente libcairoavec changement de correctif src/cairo-xlib-display.cen définissant display->buggy_gradientstoujours TRUE(à partir d' un message sur les forums Debian ) (pensez à l'épingler également, au cas où les futures libcairo2mises à jour n'auraient toujours pas le correctif).

Cela a finalement résolu mes problèmes.

MISE À JOUR

Ceci est censé être corrigé dans le pilote Nvidia 304.30 publié le 30/07/2012. Depuis le journal des modifications (pas encore en ligne, car NvNews a récemment été piraté récemment et la propre page de Nvidia n'héberge pas spécifiquement le journal des modifications, mais il se trouve dans le package binaire qu'ils fournissent):

- 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.

MISE À JOUR 2

... et maintenant cette version du pilote a atteint Debian Unstable, au moins.

— Daniel Andersson
source

Étant donné que les onglets de Google Chrome sont trapézoïdaux, ils utilisent une fonction spécifique dans le pilote appelée "accélération trapézoïdale", qui est prise en charge dans le matériel par les circuits Nvidia plus récents .

Sur les circuits plus anciens sans ce support, il y avait un bogue qui s'est présenté en combinaison avec les mises à niveau vers X.org 1.11 (où je suppose que X.org a commencé à prendre en charge le rendu trapézoïdal direct) qui a rendu le rendu trapézoïdal beaucoup plus lent qu'il ne devrait l'être (beaucoup plus lent qu'avec les anciennes combinaisons pilote / serveur X.org). Je lance une GeForce 9400 qui est l'un des circuits concernés.

Le rapport de bogue Debian .

L'annonce du correctif du pilote Nvidia dans 290.03 .

Personnellement, j'ai eu ce problème avec des versions de Nvidia encore plus récentes (295.40), qui ont persisté pendant un redémarrage, mais pour une raison quelconque, le simple lancement a nvidia-settingscorrigé le problème .

Chrome est encore beaucoup plus lent que par exemple Opera dans la commutation et la création d'onglets sur ma machine, mais il n'induit plus de retards de plusieurs secondes. De tout ce que je peux dire, c'est de retour à la vitesse qu'elle était avant l'introduction du bug.

EDIT: Ces informations sont tout aussi vraies qu'auparavant, mais il y avait un bug supplémentaire qui affectait toutes les cartes Nvidia. Voir mon autre réponse pour plus d'informations.

— Daniel Andersson
source