Google Chrome नया टैब रेंडर करने से पहले कुछ समय के लिए हैंग हो जाता है


9

जब भी मुझे एक टैब के अलावा किसी अन्य टैब पर स्विच करना होता है जो क्रोम प्रदान करता है, तो नया टैब रेंडर करने से पहले क्रोम लगभग 2 सेकंड तक लटका रहता है। यह तब होता है जब भी कोई नया टैब दिखाना होता है, जैसे "नया टैब" बटन पर क्लिक करना, या वर्तमान टैब को बंद करना।

यहाँ मेरे संस्करण की जानकारी है:

Google Chrome 14.0.835.163 (आधिकारिक बिल्ड 101024)

OS: लिनक्स (Ubuntu 11.04)

WebKit 535.1 (शाखाएं / क्रोमियम / 835 @ 94713)

मेरे द्वारा उपयोग किया जाने वाला एकमात्र एक्सटेंशन Adlock है, और इसे अक्षम करने का कोई प्रभाव नहीं पड़ा।

यह केवल मेरे साथ घटित हुआ है क्योंकि मैंने क्रोम के सबसे हाल के संस्करण को अद्यतन किया है।

क्या चल रहा है इसका कोई अंदाजा?


क्या आपने "नया टैब" - डिफ़ॉल्ट को अक्षम करने का प्रयास किया है? आप एक्सटेंशन "न्यू टैब रीडायरेक्ट" के साथ ऐसा कर सकते हैं । इसे बदलने का प्रयास करें about:blank। इससे क्या फ़र्क पड़ता है?
डुइजफ

मुझे यकीन नहीं है कि मैं स्पष्ट था। ऐसा तब भी होता है, जब मेरे पास दो टैब खुले हों, एक www.google.com पर, और दूसरा www.youtube.com पर, और मैं एक से दूसरे पर स्विच करना चाहता हूं (समस्या, सामग्री पर निर्भर नहीं करता है टैब के बारे में: मेरे पास लगभग दो टैब हो सकते हैं: संस्करण, और उनके बीच स्विच करना देरी का कारण बनता है)।
एलेक्स डायस

जहाँ तक मैं देख पा रहा था, वहाँ इस समस्या के बारे में कोई बग रिपोर्ट नहीं थी। क्या यह एक परस्पर विरोधी अनुप्रयोग हो सकता है?
डुइजफ

शायद, हालांकि यह तब भी होता है जब बहुत अधिक नहीं चल रहा हो। इससे पहले कि मैंने क्रोम को अपडेट किया (जो समस्या का कारण था), मैंने gcc-4.4, g ++ - 4.4 और उनकी निर्भरताएँ (मुझे gcc और g ++: 4.4 और 4.5 दोनों के दो संस्करण दिए) स्थापित किए। हालाँकि, लाइव सीडी पर ऐसा करने से कोई समस्या नहीं हुई, इसलिए मुझे लगता है कि gcc और g ++ के दो संस्थापित संस्करण समस्या का कारण नहीं हैं। इसके अलावा, मैंने अभी क्रोमियम स्थापित किया है, और समस्या वहां मौजूद नहीं है।
एलेक्स डायस

दिलचस्प बात यह है कि 2012-04-13 को एक नए संस्करण में अपडेट करने के दौरान यह मेरे लिए अभी शुरू हुआ। अब यह स्थिर, अस्थिर और बीटा बिल्ड के साथ होता है। मैं इस विषय पर कई अन्य आंतरायिक बग रिपोर्ट देखता हूं, लेकिन कोई वास्तविक उत्तर नहीं है। मैं जांच जारी रखूंगा।
डैनियल एंडरसन

जवाबों:


4

मुझे उन टैब के साथ एक अपरिचित व्यवहार का सामना करना पड़ा जो पहले कभी नहीं थे और कभी-कभी सामने आने पर भी पृष्ठभूमि में प्रस्तुत नहीं किया गया था। सौभाग्य से मुझे याद आया कि GPU- कम्पोज़िटिंग के बारे में सक्रिय किया गया है: झंडे (जो एक या दो सप्ताह पहले तक ठीक थे)। इसे अस्वीकार कर फिर से इस मुद्दे को हल कर दिया।


अजीब, इस वास्तव में क्रोम पर प्रतिपादन की प्रक्रिया को गति दी।
मावलकर

1

मैंने अभी अभी libcairo2डेबियन सिड में एक और मुद्दे पर नज़र रखी है । डेबियन बग # 682308 देखें ।

इसके साथ cairo-1.12.0, Google क्रोम और क्रोमियम में टैब स्विचिंग और नए टैब खोलने के कारण एक प्रतिगमन बग होता है जो महत्वपूर्ण रूप से स्टॉप और xorgसीपीयू उपयोग को रोक देता है ।

बग रिपोर्ट में तीन अलग-अलग वर्कअराउंड का उल्लेख किया गया है, एक अपस्ट्रीम फिक्स का इंतजार:

  • चल रहा है

    nvidia-settings -a InitialPixmapPlacement=0
    
  • संस्करण के लिए पिनिंग पैकेज 1.10.2-7
  • हाल ही में ( डेबियन मंचों पर एक पोस्ट से) होने के लिए सेटिंग में libcairoबदलाव के साथ पैच का निर्माण करना ( इस पर भी विचार करना, अगर भविष्य के अपडेट में अभी भी इस सुधार की कमी है)।src/cairo-xlib-display.cdisplay->buggy_gradientsTRUElibcairo2

इससे आखिरकार मेरे मसले हल हो गए।

अपडेट करें

यह कथित रूप से एनवीडिया चालक में तय किया गया है। 304.30 2012-07-30 जारी किया गया। चेंजलॉग से (अभी तक ऑनलाइन नहीं है, एनवीएनयूएस के कारण हाल ही में हाल ही में हैक किया गया था और एनवीडिया का अपना पेज विशेष रूप से चैंज को होस्ट नहीं कर रहा है, लेकिन यह उनके द्वारा प्रदान किए गए बाइनरी पैकेज के अंदर है):

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

अद्यतन २

... और अब इस ड्राइवर संस्करण ने कम से कम, डेबियन अनस्टेबल को हिट किया है।


0

चूंकि Google क्रोम के टैब ट्रेपेज़ोइडल हैं, इसलिए वे "ट्रेपेज़ॉइडल त्वरण" नामक ड्राइवर में एक विशिष्ट फ़ंक्शन का उपयोग करते हैं, जो नए एनवीडिया सर्किट द्वारा हार्डवेयर में समर्थित है ।

इस समर्थन के बिना पुराने सर्किटों पर, एक बग था जो X.org 1.11 में अपग्रेड के साथ संयोजन में दिखाया गया था (जहां मुझे लगता है कि X.org ने प्रत्यक्ष ट्रैपेज़ॉइडल रेंडरिंग का समर्थन करना शुरू कर दिया था) जिसने ट्रैपेज़ॉइडल रेंडरिंग की तुलना में बहुत धीमी गति से किया जाना चाहिए (बहुत अधिक होना चाहिए) पहले के ड्राइवर / X.org सर्वर संयोजन के साथ यह धीमा था)। मैं एक GeForce 9400 चलाता हूं जो प्रभावित सर्किटों में से एक है।

डेबियन बग रिपोर्ट

एनवीडिया चालक 290.03 में घोषणा को ठीक करता है

व्यक्तिगत रूप से मेरे पास यह मुद्दा नए एनवीडिया संस्करण (295.40) के साथ भी था, जो एक पुनरारंभ के माध्यम से बना रहा, लेकिन किसी कारण से nvidia-settingsइसे शुरू करने का कोई कारण नहीं था।

मेरी मशीन पर टैब स्विचिंग और निर्माण में ओपेरा की तुलना में क्रोम अभी भी बहुत धीमा है, लेकिन यह अब कई सेकंड के विलंब को प्रेरित नहीं करता है। सभी से मैं बता सकता हूं, यह बग की शुरुआत से पहले की गति से वापस आ गया है।


EDIT: यह जानकारी पहले की तरह ही सही है, लेकिन एक अतिरिक्त बग था जो सभी Nvidia कार्ड को प्रभावित करता था । अधिक जानकारी के लिए मेरा अन्य उत्तर देखें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.