Google Chrome si blocca brevemente prima di eseguire il rendering di una nuova scheda

Ogni volta che voglio passare a una scheda diversa da quella visualizzata, Chrome si blocca per circa 2 secondi prima di eseguire il rendering della nuova scheda. Ciò si verifica ogni volta che deve essere mostrata una nuova scheda, ad esempio facendo clic sul pulsante "Nuova scheda" o chiudendo la scheda corrente.

Ecco le informazioni sulla mia versione:

Google Chrome 14.0.835.163 (build ufficiale 101024)

Sistema operativo: Linux (Ubuntu 11.04)

WebKit 535.1 (rami / cromo / 835 @ 94713)

L'unica estensione che utilizzo è AdBlock e la disabilitazione non ha avuto alcun effetto.

Questo è successo solo da quando ho aggiornato la versione più recente di Chrome.

Qualche idea di cosa sta succedendo?

— Alex Dias
fonte

Hai provato a disabilitare la pagina "Nuova scheda" predefinita? Puoi farlo con l'estensione "Nuovo reindirizzamento scheda" . Prova a cambiarlo in about:blank. Fa qualche differenza?

— Duijf,

Non sono sicuro di essere stato chiaro. Questo succede anche se ho due schede aperte, dì una su www.google.com e un'altra su www.youtube.com e voglio passare dall'una all'altra (inoltre, il problema non dipende dal contenuto delle schede: posso avere due schede su about: version e il passaggio da una all'altra provoca il ritardo).

— Alex Dias,

Per quanto ho potuto vedere, non c'erano segnalazioni di bug su questo problema. Potrebbe essere un'applicazione in conflitto?

— Duijf,

Forse, anche se questo accade anche quando non c'è molto altro in esecuzione. Poco prima di aggiornare Chrome (che ha causato il problema), ho installato gcc-4.4, g ++ - 4.4 e le loro dipendenze (dandomi due versioni di gcc e g ++: 4.4 e 4.5). Tuttavia, farlo su un cd live non ha causato problemi, quindi immagino che le due versioni installate di gcc e g ++ non siano ciò che sta causando il problema. Inoltre, ho appena installato Chromium e il problema non esiste.

— Alex Dias,

È interessante notare che questo ha cominciato a succedere a me proprio ora durante l'aggiornamento a una nuova versione il 13/04/2012. Ora succede con build stabili, instabili e beta. Vedo molte altre segnalazioni di bug intermittenti su questo argomento, ma nessuna risposta reale. Continuerò le indagini.

— Daniel Andersson,

Risposte:

Ho riscontrato un comportamento simile con le schede che non erano più (pre) renderizzate in background e, a volte, nemmeno quando venivano visualizzate in primo piano. Fortunatamente mi sono ricordato di aver attivato il GPU-Compositing in circa: flags (che ha funzionato bene fino a una o due settimane fa). Disabilitarlo di nuovo risolto questo problema.

— Maximilian Jänicke
fonte

Strano, questo REALMENTE ha velocizzato il processo di rendering su Chrome.

— mowwwalker,

Ho appena rintracciato anche un altro problema con libcairo2attualmente in Debian Sid. Vedere Debian bug # 682.308 .

Con cairo-1.12.0, c'è un bug di regressione che causa il cambio di tabulazione e l'apertura di nuove schede in Google Chrome e Chromium si blocca in modo significativo e aumenta xorgl'utilizzo della CPU.

Tre diverse soluzioni alternative sono menzionate nella segnalazione di bug, in attesa di una correzione a monte:

In esecuzione

nvidia-settings -a InitialPixmapPlacement=0

Appuntamento del pacchetto alla versione 1.10.2-7.
Costruire recenti libcairocon il cambio di patch src/cairo-xlib-display.cimpostando display->buggy_gradientsdi essere sempre TRUE(da un post sui forum Debian ) (considerare di bloccarlo anche nel caso in cui i futuri libcairo2aggiornamenti non abbiano ancora risolto il problema).

Questo ha finalmente risolto i miei problemi.

AGGIORNARE

Questo è presumibilmente corretto nel driver Nvidia 304.30 rilasciato il 30/07/2012. Dal log delle modifiche (non ancora online, a causa della recente violazione di NvNews recentemente e della pagina di Nvidia che non ospita specificamente il log delle modifiche, ma è all'interno del pacchetto binario che forniscono):

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

AGGIORNAMENTO 2

... e ora questa versione del driver ha colpito Debian Unstable, almeno.

— Daniel Andersson
fonte

Poiché le schede di Google Chrome sono trapezoidali, usano una funzione specifica nel driver chiamata "accelerazione trapezoidale", che è supportata nell'hardware dai più recenti circuiti Nvidia .

Sui circuiti più vecchi senza questo supporto, c'era un bug che si presentava in combinazione con gli aggiornamenti a X.org 1.11 (dove immagino che X.org avesse iniziato a supportare il rendering trapezoidale diretto) che rendeva il rendering trapezoidale molto più lento di quanto avrebbe dovuto essere (molto più lento di quanto non fosse con le precedenti combinazioni di driver / server X.org). Corro una GeForce 9400 che è uno dei circuiti interessati.

Il rapporto sui bug di Debian .

L'annuncio della correzione del driver Nvidia nel 290.03 .

Personalmente ho avuto questo problema con versioni Nvidia ancora più recenti (295.40), che sono persistite attraverso un riavvio, ma per qualche motivo il solo lancio lo ha nvidia-settingsrisolto.

Chrome è ancora molto più lento di quello di Opera nella commutazione e creazione di schede sulla mia macchina, ma non provoca più ritardi di alcuni secondi. Da tutto ciò che posso dire, è tornato alla velocità che era prima dell'introduzione del bug.

EDIT: Queste informazioni sono vere come prima, ma c'era un bug aggiuntivo che riguardava tutte le schede Nvidia. Vedi la mia altra risposta per ulteriori informazioni.

— Daniel Andersson
fonte