Cinnamon: إعادة رسم النافذة التأخر عند سحب النوافذ

أكره أن أقول "أنا أيضًا" ، لكن ... "أنا أيضًا!" أنا أركض على صندوق قديم إلى حد ما ، مع تشغيل Cinnamon أعلى Ubuntu 13.04. يبدو أن كل شيء آخر على ما يرام ، إنه مجرد سحب نافذة يمثل مشكلة. و "التلعثم" ملحوظ ، وبعد ذلك تنتقل النافذة إلى النقطة التالية. يبدو أنه يحدث عند سحب أي نافذة (كروم ، uxterm). اسمحوا لي أن أعرف ما هي المعلومات الداعمة الأخرى التي يمكنني تقديمها. لا يمكنني العثور على أي شيء مثير للاهتمام في سجلات نظامي.

يمكنني تأكيد ذلك ، لكن لدي بطاقة رسومات سيئة للغاية ...

أواجه نفس هذه المشكلات أيضًا. أقوم بتشغيل أحدث إصدار من Cinnamon من PPA الليلي على Ubuntu 13.10.

أقوم بتشغيل نظام متعدد الرؤوس على قوس لينكس مع القرفة 2.0.2 حاليًا (3 × 1920 × 1080) لقد جربت كلاً من 660 و 7870 الخاص بي. كلاهما يتصرفان بنفس السلوك ، نوافذ شديدة التأخر عند الحركة أو تغيير الحجم. أنا باستخدام أجهزة الصراف الآلي مفتوحة المصدر. (سنحاول المحفز بمجرد تحديثه للعمل)

على جهازي يكاد لا يطاق.

- تحديث - إذا قمت بالتعطيل في لوحة إعدادات Cinnamon -> Window Tiling and Edge Flip -> Window Tiling and Snapping - تتحرك النوافذ مرة أخرى بسرعة عبر الشاشة ؛ حصلت على هذا التلميح من خلال التنقل في النافذة وحصلت على شيء HUD الجديد الذي يوضح لي الوضع الذي يمكنني وضع تلك النافذة ؛ كلما ظهر HUD ، سيبدأ التأخر.

يمكنني تأكيد نفس السلوك على جهاز الكمبيوتر المحمول الخاص بي ؛ باستخدام Manjaro Linux و Cinnamon 2.0.6
لدي وحدة معالجة مركزية ثنائية النواة P6100 وبطاقة رسومات Intel HD 3000.
لم أواجه هذه المشكلة من قبل مع 1.6 أو 1.8.
كنت أبحث عن خيار مع Muffin لتعطيل "محتوى النافذة" أثناء التنقل ولكن لم يحالفني الحظ حتى الآن ، باستخدام محرر Dconf.
سيكون من الرائع أن يقدم شخص ما تفسيرًا لحدوث ذلك.
ثابر على العمل الجيد ؛)!

التأخير في سحب النوافذ ليس شيئًا مقارنةً بتغيير حجم النوافذ (على سبيل المثال: gnome-terminal) ، يمكن أن يستغرق عدة ثوانٍ :-(

أؤكد هذا الخطأ باستخدام وحدة تحكم Intel core I5 ​​و Intel الرسومية (الجيل الثاني).

يمكنك ضبط عتبة HUD للبلاط على 1 وستقوم بشكل أساسي بتعطيل عرض HUD مع الاستمرار في تمكين التجانب. ربما في الإصدار التالي ، يمكن إضافة طريقة أكثر مباشرة لتعطيله ، إلى جانب مجموعة أكثر قوة من الرسومات لتحريك HUD.

يمكنني تأكيد هذا الخطأ على i7-2600K CPU و AMD R9290 GPU (أحدث برامج التشغيل التجريبية). خاصة على شاشتي 120 هرتز. لم يساعد تعطيل التبليط والانعكاس.

ما هو إصدار Cinnamon الذي تستخدمه؟ تم تصحيح أحد أسباب ذلك مؤخرًا نسبيًا.

https://github.com/linuxmint/muffin/commit/403d24edc854c6610ff46427b6cf2072fa62bfa5

أنا أقوم بتشغيل Cinnamon 2.0.14. سنحاول تثبيت الأحدث.

ربما يكون الحصول على أحدث فطائر المافن أكثر أهمية. إذا كنت تستخدم muffin 2.0.4 فلا يوجد لديك الإصلاح بعد. إذا قمت بتشغيل 2.0.5 فسوف تحصل عليه.

(لا أضمن أن مشكلتك الخاصة قد تم إصلاحها ، فقد تكون سببًا آخر محتملًا ، لكن الأمر يستحق التحقق)

أواجه شيئًا مشابهًا مع Cinnamon 2.0.14 و Muffin 2.0.5 على Mint 16 مع i5-4440s مع رسومات Intel HD 4600. عندما أقوم بسحب Windows ، لا يمكنهم مواكبة مؤشر الماوس. يبدو الأمر كما لو أن النوافذ متصلة بالمؤشر بشريط مطاطي صغير.

هذا مقطع فيديو لما أواجهه. هل هذا سلوك طبيعي؟ http://youtu.be/KylzMTZpD7w

يمكنني أن أؤكد أن هذه الحالة لا تزال صالحة لـ Cinnamon 2.2.14 وكذلك Gnome Shell 3.12.2 على Debian Jessie.

لقد فهمت هذا أيضًا ، ومن المشتت حقًا أن أكون صادقًا. أقل سلاسة بشكل ملحوظ من Unity وما إلى ذلك ، وفي الواقع Windows ...

أعاني من نفس الشيء الذي اشتكيت منه سابقًا ، ولكن أيضًا مع NVidia GTX 760. المشكلة بالتأكيد أسوأ مع الشاشات المتعددة.

أحصل على هذا على Cinnamon 2.2.14 أيضًا ، مع NVidia GT 630 مع إصدار برنامج التشغيل الخاص 340.24 (وشاشتان). عند الرجوع إلى إصدار برنامج التشغيل 304 ، تتحرك النوافذ بسرعة مرة أخرى ، ولكن بعد ذلك أشعر بالتمزق.

في الأحد 10 أغسطس 2014 04:04:47 صباحًا بتوقيت شرق أوروبا ، كتب أندريس مانز:

أحصل على هذا في Cinnamon 2.2.14 أيضًا مع NVidia GT 630 مع
إصدار سائق خاص 340.24 (وشاشتان). عند التخفيض
إلى الإصدار 304 من برنامج التشغيل ، تتحرك النوافذ بسرعة مرة أخرى ، ولكن بعد ذلك
تجربة تمزق.

يختفي تأخر سحب النافذة عندما يتم تعطيل vsync عبر ملف
متغيرات البيئة. لا يقوم برنامج التشغيل AFAIK Nvidia 304 بتمكين vsync بواسطة
افتراضي (على عكس الأحدث) ، لذلك قد يفسر سبب صيامك
السحب والتمزيق عند الرجوع إلى إصدار سابق.

ومع ذلك ، ينتشر استخدام CPU عالي بغض النظر عن vsync.

يمكن أن أؤكد أن النوافذ أقل تباطؤًا إذا لم أحاول تمكين vsync (برامج تشغيل Intel) ، ولكن بعد ذلك لا يمكن مشاهدة مقاطع الفيديو.

من الغريب أيضًا أن لينكس منت لا يحتوي على هذا الخطأ ، ولديه قوس لينكس.

startas لا ، أحصل عليه في Mint 17.

حتى أكثر غرابة منذ أن نشرت في هذا العدد ، لم أواجه المشكلة مرة أخرى. لقد قمت منذ ذلك الحين بتثبيت القرفة على عدة تكوينات مختلفة للأجهزة والأجهزة والبرامج (التوزيعات).

إنه أمر غريب - "تم حل" هذه المشكلة (لدي فقط رسومات Intel عالية الدقة ، لذلك قد تعمل فقط مع رسومات Intel) عن طريق إعادة تجميع xf86-video-intel مع العلم "--disable-DIR3" ، وإعادة تجميع lib32-mesa بنفس علم "--disable-dra3" ، بالطبع يجب عليك أيضًا إزالة العلم "--enable-dra3".
بينما أستخدم نظام 64 بت لينكس ، فإن تجميع حزمة ميسا 64 بت بدون DIR3 وتثبيته يؤدي إلى تعطل سطح مكتب القرفة ، ولكن بطريقة ما إعادة تجميع إصدار xf86-video-intel فقط وإصدار 32 بت من mesa لأنظمة 64 بت "حل هذه المشكلة" ، إصلاح تأخر كبير في الكروم.
لا يعمل فقط تعطيل DR3 في برامج التشغيل ثنائية الأبعاد ، ولكن تعطيل DIR3 في إصدار 32 بت من ميسا وتثبيته نجح ، أتساءل لماذا - لم يتم تثبيت هذه الحزمة بشكل افتراضي ، حيث يستخدم لينكس 64 بت قرفة 64 بت ، لذلك يستخدم 64 بت ميسا ، وليس لدي أي فكرة عن كيفية عملها: د

باستثناء وجود مشكلة واحدة في ذلك ، لم يكن DRI3 موجودًا عند إنشاء هذه المشكلة لأول مرة.

حاليا أرك لينكس أيضا تعطيل DRI3 بشكل افتراضي على ما أعتقد؟

يبدو أن هذه المشكلة قد تكون مرتبطة بشيء أراه في برنامج Kerbal Space على Linux (مع Cinnamon): إطارات عمل مثالية ، إلا عندما أقوم بالنقر فوق الماوس مع الاستمرار في الدوران حول صاروخ - ثم يتلعثم ويقفز بشكل سيء. القرفة ربما تقوم بنوع من الحجب في حلقة إعادة الرسم لأحداث الفئران؟

في نظام arch linux ، يتم تجميع xf86-video-intel دون حدوث بالتنقيط 3 ، ولكن يتم تجميع الميسا باستخدام DIR3.

على جهاز الكمبيوتر الخاص بي سريعًا جدًا ، يعد تغيير حجم النوافذ باستخدام القرفة أمرًا مؤلمًا وأحب أن يكون لدي خيار لتعطيل التصور الفعلي لمحتوى النافذة. xfce يفعل ذلك بطريقة جيدة جدا.

هذا يحدث ولكن فقط على شاشتي الخارجية ، على جهاز Macbook ("أواخر 2014") مع رسومات intel. ستعرض النافذة أيضًا القطع الأثرية الممزقة ، مرة أخرى فقط على الشاشة الخارجية. لا يتغير التأخير بشكل ملحوظ إذا قمت بتمكين "TearFree" ولكنه يصلح التمزق. أقوم بتوسيع نطاق الشاشة الخارجية 2x2 باستخدام xrandr.

تحرير: يجب أن أشير إلى أن شيئًا مثل glxgears لا يعاني من انخفاض معدل الإطارات إذا قمت بسحبه على تلك الشاشة ، في الواقع كان يبلغ عن 71 إطارًا في الثانية على شاشة 60 هرتز ، على الرغم من الحركة التي تجعلها تبدو أقل من 10 إطارات في الثانية. تركه بمفرده يعمل بشكل طبيعي.

تحرير 2: يبدو أن القياس لا يغير التأخير أيضًا.

wrouesnel وغيرها ...

من المحتمل أن تكون مشكلة KSP على وجه التحديد بسبب تعيين معدل اقتراع الماوس لديك مرتفعًا جدًا ، خاصةً إذا كان لديك ماوس ألعاب ، مثل Razer DeathAdder أو ما شابه (الذي أستخدمه). يجب أن يساعد البرنامج التعليمي التالي:

https://patrickmn.com/aside/lowering-gaming-mouse-sensitivity-in-ubuntu-9-10/

لقد سجلت مقطع فيديو يظهر مشكلة لدي (مشكلة سحب متصفح Chromium ، بينما يتم تشغيل Nemo و Firefox للمقارنة فقط): https://youtu.be/Ec99EYjwiqY
لدي نفس المشكلة مع IntellJ وأحيانًا مع Pidgin أو مرات أقل مع Nemo. أنا أستخدم Mint 17.3 و Cinnamon 2.8.6 مع برامج تشغيل خاصة. أشياء يجب ملاحظتها:

- نعناع 17.3 مع قرفة 2.8.6
-لا يمكن تحميل برامج تشغيل gpu مفتوحة المصدر لاختبارها ، فقد أبقاني في وضع عرض البرامج الآن (أتذكر أن المصدر المفتوح xorg كان يعمل جيدًا عندما قمت بتثبيت 17.0 Mint مرة أخرى قبل بضعة أشهر)
- يساعد إجبار vsync المعطل في AMD Propietary CCC على تقليل تأخر النوافذ قليلاً ، ولكنه يجعل تمزيق الشاشة خاصًا أثناء التمرير على مواقع الويب
-عندما بدأت Cinnamon ، كل شيء يعمل بشكل جيد ، لا توجد نوافذ جر بطيئة ، ولا تغيير في الحجم. المشكلة موجودة بعد مرور بعض الوقت (على سبيل المثال ، بعد 10-40 دقيقة من بدء Chromium)
- إعادة تشغيل القرفة (ctrl + alt + esc) تساعد بشكل مؤقت (فوق النقطة)
- (عدل): لم يحدث ذلك من قبل في 17.2 و Cinnamon 2.6 إذا كنت أتذكر بشكل صحيح ، لكن كان لدي مشكلة أكبر في التمزق في ذلك الوقت.

تعديل:
نفس الأشياء تحدث باستخدام برامج تشغيل مفتوحة المصدر ، تمكنت من إعادة تثبيتها.

تشغيل النعناع الطازج 17.3 سينامون من USB ، نفس المشكلة كما هو موضح أعلاه.
فحصت Ubuntu Gnome3 و Ubuntu Mate للمقارنة. أثناء تشغيل كلاهما من USB لفترة طويلة لم ألاحظ أي مشاكل / تباطؤ.

بطريقة ما يبدو أنه مرتبط بـ GPU ، يحدث بشكل خاص للبرامج التي تدعم GPU ، مثل Chromium.
الشيء الثاني الذي يجب ملاحظته هو أنه يبدو أنه يحدث بشكل أسرع أثناء وجود intelihide في menubar والاستمرار في ثقب menubar مع نافذة Chromium. يمكنني سماع المعجبين في الكمبيوتر المحمول يبدأون في العمل بصوت أعلى. من الأفضل سحب نافذة Chromium عن طريق الدوران فوق سطح المكتب.

تمكين / تعطيل "تعطيل إنشاء النوافذ بملء الشاشة" - بدون تغيير

إنه بطيء في استنساخه حتى مع اللكم menubar ، أسهل طريقة هي ببساطة تصفح الإنترنت لبعض الوقت ، لكنني أفهم أنه يمكن أن يكون الجحيم لتصحيح الأخطاء.

لدي هذه المشكلة أيضًا - لكن ما لاحظته هو أن النوافذ تحصل على _laggy_ بعد مرور بعض الوقت - ولكن إذا فتحت نوافذ جديدة ، فلن يتم تأخيرها.

على سبيل المثال ، إذا تركت محطة تجلس هناك لمدة ساعة ، فستتلعثم أثناء السحب قليلاً ، لكن المحطة الطرفية المفتوحة حديثًا ستعمل بشكل جيد.

ونعم هذا عندما يكون لدي كروم مفتوح (وهو مفتوح بشكل أساسي طوال الوقت).

إنها ليست مشكلة كبيرة حيث يبدو أن كل الجوانب الأخرى تعمل بشكل جيد (على سبيل المثال ، لا تلاحظ المزيد من التأخير في الألعاب أو شيء ما) - الشيء الغريب الآخر الوحيد الذي لاحظته هو أن شاشة القفل تستغرق حوالي 10 ثوانٍ. للتحميل (لم ألحظ ذلك قبل أن أقوم بالانتقال إلى Mint 17.3)

ملاحظة: لقد لاحظت أن عملية cinnamon --replace ستُظهر استخدامًا مرتفعًا جدًا لوحدة المعالجة المركزية (حوالي 16٪ على نظامي) في بعض الوقت بعد أن قمت بنقل نافذة _laggy_.

معطل intellihide ، تعيين لوحة لعرض دائما. يعمل حاليًا بنظام التشغيل لساعات قليلة ومفاجأة! لا تأخير! أشعر وكأنني في الجنة.

يمكنني تأكيد تأخر النافذة خلف المؤشر ، في Linux Mint 17.3 ، Cinnamon 2.8.6 ، مع برنامج التشغيل الخاص بـ nvidia 352.63. مزعج جدا! المشكلة مستقلة عن التركيب ممكن أم لا!

يمكنني أيضًا تأكيد التأخر باستخدام Mint 17.3 و Cinnamon 2.8.6 والرسومات المدمجة من i5-4210U أو nVidea GeForce 820M.
لقد لعبت قليلاً مع إعدادات لوحة العرض / الإخفاء ويبدو أن التأخر موجود فقط عند عرض اللوحة. عندما أقوم بتعيينه على إخفاء تلقائي لجميع عمليات سحب النافذة ، تكون سلسة.
(نعم أعلم أن هذا هو عكس تعليق DarekDeo تمامًا).

ربما ليس العكس تمامًا ، من كلا التعليقين يبدو أن هناك خطأ ما في اللوحة. :)

تحرير: أو على الأقل ذات الصلة به.

لدي هذه المسألة أيضا. أي شخص جرب برنامج تشغيل رسومات مختلف؟ واجهت هذه المشكلة في Xubuntu 15.10 وبمجرد أن قمت بتغيير برنامج التشغيل ، كل شيء سار على ما يرام. لا يمكنني العثور على هذا الخيار هنا؟ أذهب إلى السائقين في لوحة الإعدادات وتظهر قائمة فارغة للتو.

الإعداد: Fedora 23، Cinnamon، GDM، Nvidia السائقين الملكية (أيضًا مع Nouveau)

أعاني أيضًا من التلعثم عند سحب النوافذ ، وكذلك عند الكتابة أو التمرير عبر ملف في Vim. على سبيل المثال ، أثناء الكتابة ، ستظهر بعض الأحرف مع ضغطة المفتاح ، ثم سيتعطل المؤشر لبضعة أجزاء من الثانية ، ثم تظهر جميع الأحرف التي كتبتها أثناء التعليق.

يبدو أن التلعثم يحدث بانتظام. إذا اضطررت إلى التخمين ، فسأقول كل 500 مللي ثانية. ومن المثير للاهتمام ، إذا قمت بتحريك نافذة بسرعة لفترة من الوقت ، فإن الجزء العلوي يظهر أن Xorg تأخذ في بعض الأحيان نسبة كبيرة من وحدة المعالجة المركزية (~ 53 ٪) عند تحريك النوافذ ... هذا لا يبدو صحيحًا. أيه أفكار؟

تحرير: قمت بتشغيل قرص Fedora 23 Cinnamon Spin Live CD ، ومن المثير للاهتمام ، أنني لم أواجه أي تلعثم. ولكن ، باستخدام نفس بيئة DM (Cinnamon و lightdm و nouveau drivers) في تثبيت محرك الأقراص الثابتة الخاص بي لا يزال يعمل. قد أحاول تثبيت Cinnamon مباشرة من Live CD على جهاز مختلف لمعرفة ما إذا كانت المشكلة قائمة ؛ سأقدم تقريرا مع أي نتائج.

واو ، حسنًا. شكرًا DarekDeo ، يعمل هذا بشكل أفضل عند تعطيل اللوحة الذكية. من المؤسف أنني لا أستطيع مشاهدة مقاطع فيديو Youtube في المشغل الكبير عندما يكون المتصفح في وضع ملء الشاشة الآن ، ولهذا السبب قمت بتشغيل هذه اللوحة في المقام الأول ، لكن النوافذ كانت سيئة.

أجد أنه من الغريب مدى تأخر جميع النوافذ ، فهي ليست غير محتملة ، ولكن إذا عدت إلى نظام التشغيل Windows ، فإن 144 هرتز الخاصة بي تجعل كل شيء يبدو ويشعر بالسلاسة ، وتتحرك النوافذ وتشعر جميعًا بالصلابة والثبات ، عد مرة أخرى يبدو نظام Linux و 60 الخاص بي أكثر سلاسة تقريبًا من نظام التشغيل 144 ونوافذ تشعر وكأنها من المفترض أن تكون بطيئة عندما تقوم بسحبها.

أريد أيضًا أن أضيف أن اللوحة الذكية يبدو أنها تؤثر على النوافذ أيضًا ، فقد كان متصفحي يتلألأ باللون الأبيض عند حدوث خلل كثيرًا ، وقد مر عددًا قليلاً من تجربته لمعرفة أي شخص لم يعد يجربه ، واعتقد أن شيئًا ما مكسورة بالقرفة أو برنامج تشغيل الرسومات الخاص بي ، تبين أن اللوحة كانت المشكلة @ _ @

حسنًا ، هذا مثير للاهتمام ، لقد لاحظت أن التلعثم الذي كنت أراه يحدث بنفس التردد الذي كان يتم فيه تحديث برنامج مراقب النظام ، لذا أزلته من اللوحة وأعدت تشغيله ، والآن اختفت التلعثم بالنسبة لي. يبدو أن هذا يدعم اقتراحDarekDeo بأن شيئًا ما قد يكون خطأ في اللوحة. ربما ، مهما كانت العملية / الشيء الذي يتم تحديثه فإنه معلق لفترة وجيزة أثناء حلقة إعادة الرسم (أنا لست مبرمج رسومات)؟

لدي نفس المشكلة في الواقع ، فقد أدى التحديث إلى إصدار أحدث من Cinnamon إلى جعله أفضل قليلاً ولكن سطح مكتب Nvidia (i5-3570k ، Nvidia 780ti) لا يزال غير سلس مثل جهاز الكمبيوتر المحمول الرسومي Intel الأقل قوة (i7-4500u ، Intel الرسومات 4400).

كلاهما يستخدم Mint 17.3 و Cinnamon 3.04 (القناة الليلية) و 4.4.0-22 kernel.

برامج التشغيل المستخدمة هي Nvidia's 364 (364.19-0ubuntu0 ~ gpu14.04.3) من برامج تشغيل Nvidia PPA وبرامج تشغيل Intel المضمنة في kernel.

@ davidva-cml شكرا لك ، إزالة برنامج Sytem Monitor الصغير حل المشكلة بالنسبة لي!

تم إيقاف تشغيل "sync to vblank" في إعدادات nvidia xserver وتغيير حجم التطبيقات مثل Telegram أصبح سلسًا مثل الزبدة الآن

هذه لا تزال مشكلة بالنسبة لي.
أنا أستخدم تثبيتًا جديدًا لـ Ubuntu 16.04.1 ، باستخدام Nvidia GTX 1070 مع إصدار برنامج التشغيل 375 ، لذلك لا ينبغي أن يكون الأداء مشكلة.

JosephMcc ، هل يمكننا تحديد هذه المشكلة على أنها خطأ؟

@ davidva-cml هل تمكنت من إصلاحه؟ أرى أيضًا Xorg أعلى استخدام وحدة المعالجة المركزية عند سحب النوافذ ... ربما يجب علينا الإبلاغ عنها باعتبارها مشكلة Xorg. على الرغم من أنه قد يكون دائمًا مشكلة Cinnamon بعد كل شيء .. أبسط طريقة لإعادة الإنتاج هي تشغيل glxgears على الخلفية أثناء سحب النوافذ حولها.

ومع ذلك ، قد يعاني بعض الأشخاص في هذه المشكلة من مشكلة تأخر مختلفة تمامًا (والتي قد تكون متعلقة بالقرفة).

أخشى أن لدي نفس المشكلة. لكن لديّ جهاز كمبيوتر قويًا حقًا (Core i7-5930K 3.5 جيجا هرتز 6 نوى + Nvidia TITAN X يشغل أحدث برنامج تشغيل nvidia + 32 جيجا بايت من ذاكرة الوصول العشوائي ونظام التشغيل الخاص بي المثبت على SSD). لذا لا ينبغي أن يكون الأداء مشكلة. لكن مع ذلك ، في كل مرة أحاول فيها سحب نافذة ، أبطئ مثل أي شخص آخر في هذا الموضوع. لكن التطبيقات الأكثر انفتاحًا لدي هي بطيئة أكثر!
عندما أراقب (htop) يمكنني أن أرى أن عملية Xorg تستغرق 90٪ أو أكثر من استخدام وحدة المعالجة المركزية. لذلك يمكن أن تأتي من Xorg ، وليس القرفة مباشرة.
يجب أن يكون من الرائع الحصول على تعليقات لفهم ما يجري هناك.
شكر.

ادارة :
Linux kernel 4.10.0 عام
FerenOS (الذي يستخدم أحدث إصدار من Linux Mint distro)
تشغيل القرفة 3.4.6

أشعر بالفضول إذا اكتشف الآخرون أي عمل حول هذا مؤخرًا لأن هذا أصبح هادئًا.

بالنسبة لي ، يبدأ Cinnamon في زعزعة الاستقرار مع تزايد هذا التأخر من إعادة التشغيل بمرور الوقت ، حتى يصبح الأمر مزعجًا للغاية ، وعادة ما أجد أنه يتعين علي إعادة تشغيله بقوة لأن الشاشة لن ​​تستيقظ من النوم بعد الآن. مثل المنشور الأخير ، إنه جهاز كمبيوتر قوي (20 مركزًا ، و 40 موضوعًا ، و Xeon مزدوج ، وذاكرة وصول عشوائي 128 جيجابايت ، و nvidia 1070 ، و nvme مزدوج ، وشاشات 3x 4k) ، لذا فإن الأداء ليس مشكلة ، ولا أحصل على هذا مع سطح المكتب الآخر بيئات أخرى غير kde (التي لها مشكلات في التركيب الخاصة بها). لقد قمت بإيقاف تشغيل vblank ومعظم ميزات gl الأخرى ، وما زلت مزعزعة للاستقرار ، عادةً في غضون أسبوع ، لكنني لم أقم مطلقًا بأي أخطاء لإخبار شيء ما.

أنا أستخدم برامج تشغيل Arch linux و Cinnamon 3.8.1-1 و 4.16.13 kernel و nvidia 396.24. أستمر في الترقية على أمل أن يختفي هذا ، لكن لا يحدث ذلك أبدًا.

على ما يبدو (كما هو الحال مع معظم أجهزة سطح المكتب الآن) فإن الإجابة هي ببساطة استخدام عرض البرامج على سطح المكتب. تمكنت من الذهاب لبضعة أسابيع في المرة الماضية قبل أن أحصل على مهلة عرض مدتها 5 ثوانٍ تقريبًا كل دقيقة أو نحو ذلك ، الأمر الذي أصبح مثيرًا للغضب بمرور الوقت.

عادةً ما أقوم بالانتقال إلى سطح مكتب مختلف ، كيدي (دعاء إصلاحه أيضًا) أو ماتي (يميل ماركو إلى التصرف ، لكن سطح المكتب ينقصه خلاف ذلك) بعد pacman -Syyu ، لكن هذه المرة لاحظت عرض برنامج القرفة الوضع. بعد أسبوع من الاستخدام العادي مع عرض البرامج ، عادةً ما أبدأ في التأخر بعد بضعة أيام ، ولكن مع وضع البرنامج ، كان الأمر سلسًا ، ولا أرى حقًا أي جانب سلبي في الأداء في استخدام سطح المكتب.

إنه لأمر مخز أن هذا الخطأ المكون يبدو أنه لا يزال قائما ، ولكن من المؤكد تقريبا أنه مرتبط بالفيديو / gl. تعد أدوات التركيب بمثابة لعنة لكل سطح مكتب من نظام التشغيل Linux أجده ، ولم أجد بعد واحدًا يتصرف بشكل صحيح ، حتى أن windoze aero الذي وجدته في 4k هو حماقة مطلقة يتم شحنها مع جهاز xps 9560 الخاص بي.

الحل الجيد هو إضافة CLUTTER_VBLANK=none إلى / etc / environment وتمكين خط أنابيب تكوين القوة على جميع الشاشات في إعدادات nvidia ضمن تكوين العرض -> خيارات متقدمة. يؤدي هذا إلى نقل معالجة vsync من المركب إلى برنامج التشغيل ، ويساعد على amdgpu أيضًا مع تمكين TearFree في تكوين xorg.

شكرًا على ذلك ، لقد قمت بتعيين بيئة / etc / بيئتي ، لكنني لم أجد حاجة لتجربة إصدار الأجهزة ، حيث يبدو أنه يدعو إلى الدراما والفوضى فقط. أنا سعيد جدًا بالإصدار الذي تم تقديمه من البرنامج حتى الآن ، وبعض التأخيرات في الرسم في cairo-dock وبعض التطبيقات الأخرى ، ولكن ليس بشكل رهيب مثل إصدار الأجهزة الذي يتغوط على نفسه.

من المثير للاهتمام ، حتى في وضع البرنامج الآن ، أنني أقوم بتطوير نفس التأخير ، ولكن بمعدل أبطأ بكثير من عرض GPU الكامل. يبدو وكأنه نوع من تسرب الموارد ، ولكن إذا لم يكن العرض المباشر ضد وحدة معالجة الرسومات (gpu) ، فسأفترض وجود بعض الأخطاء في إدارة الموارد داخل سطح المكتب.

ما هي الملاحظات المفيدة والسجلات وتصحيح الأخطاء وما إلى ذلك للمساعدة في إصلاح ذلك؟ لا أرى شيئًا غير طبيعي في أي مكان ، بخلاف سطح المكتب الذي يخاف على فترات عشوائية / مشتركة.

للتوضيح أيضًا ، أعتقد أن الكثير من هذا يتعلق بالقرارات العالية التي أستخدمها في هذا. يعمل سطح المكتب عند 11520 × 2160 (شاشات 3 × 4 ك) ، مما يفرض ضرائب على أي سطح مكتب أجده حتى أنه يحاول تسريع وحدة معالجة الرسومات. لا أعتقد أن أي شخص يتعامل مع هذا النوع من الأشياء ، ولكن مع ظهور 4k و 5k و 8k الآن ، فإن الصراع حقيقي. هذا هو السبب في أن التركيب يبدو أنه ينكسر تحت أي سطح مكتب ، بما في ذلك الوحدة ، أو kde ، أو القرفة ، أو حتى ماتي / ماركو مع عرض مباشر ضد وحدة معالجة الرسومات على هذا النطاق.

إنه شيء يجب ملاحظته للمطورين ، لقد كان مقياس الدقة للعرض المركب بشكل صحيح مشكلة منذ ~ 2010 عندما كنت أقوم بتشغيل شاشات 6 × 1080 بكسل تحت لينكس مع ظهور التركيب.

لذا عدت مرة أخرى للتحقق من هذا ، بعد أن عانيت من تأخيرات لمدة 5 ثوانٍ في إعادة رسم النافذة ضمن تكوين البرنامج مؤخرًا بعد حوالي 80 يومًا من وقت التشغيل ، قمت بالترقية مرة أخرى لمعرفة ما هو جديد وآمل أن يتحسن. قصة قصيرة طويلة: ليس كثيرًا.

الآن في 4.0.7 حزم القرفة الأساسية ، والتشغيل مع عرض البرامج كما كان من قبل كان سيئًا مع الخفقان الرهيب ومشكلات التحديث الغريبة حول أجزاء من النوافذ (على سبيل المثال ، أزرار التصغير / الخروج بشكل خاص). عند محاولة وضع الأجهزة ، يعمل بدون ذلك ، ولكن على الفور تقريبًا بدأت في الحصول على تأخر في التحديث في غضون أيام قليلة من الاستخدام الذي ينمو باطراد كما كان الحال في السابق مع وضع الأجهزة الذي دفعني إلى استخدام البرنامج. يبدو البرنامج بمثابة سلة في 4.0 حتى الآن ، ولكن لا يزال عرض الأجهزة يواجه هذه المشكلة منذ سنوات.

ما الذي قد يتطلبه الأمر لإصلاح هذا بالفعل؟ لا تقل الدقة في شاشات العرض ، ولا يبدو أن هذه التركيبات قادرة على التعامل مع أي شيء يتجاوز الدقة القديمة عالية الدقة.

لم يكن المقصود من وضع عرض برنامج mikebutash مطلقًا استخدامه أثناء تحميل برنامج تشغيل الرسومات. إنه لوضع VGA.

هناك مجموعة متنوعة من العلاقات العامة مفتوحة 4.2. إذا كنت تشعر بالراحة في اختبارها ، يمكنك التحقق من فروع العلاقات العامة الخاصة بي على Muffin repo. سيكون الخيار الآخر هو تعطيل vsync في الإعدادات -> عام وتمكين خط أنابيب تكوين القوة في إعدادات nvidia. لا يوجد شيء آخر يمكن القيام به لإصلاح هذا الأمر لسلسلة 4.0.x.

تحرير: راجع أيضًا صفحة wiki هذه.

jaszhix ، وافق على أنه لا يعني أن يكون حلاً ، لكنه يقول شيئًا أنه يعمل بشكل أفضل من طريقة الأجهزة المفضلة ، خاصة بمرور الوقت. ليس كثيرًا في الإصدار 4.0 الأحدث ، ومع ذلك ، فإن الانحدار الآخر مع التأخر الشديد والتأخر الشديد ، وعلى الفور بدأ التأخير المتزايد مرة أخرى على الأجهزة. حقيقة أنه يزداد سوءًا بمرور الوقت تُظهر عدم استقرار الكود ، وهو ما حدث منذ بداية 3.x ، ومن المحتمل أن يكون في 4.2 ، لذلك أشك في أن الإصدار الذي أستخدمه بالفعل مهم.

لقد قمت بكل من VSync وخط الأنابيب الإجباري لكل توصية سابقة ، لكنني لاحظت التحقق الآن من أن خط أنابيب التكوين الكامل للقوة قد تم تعطيله مرة أخرى في إعدادات nvidia ، لذا أعد التمكين وسأرى كيف تكون هذه الأسعار. ما زلت أرى بالفعل تأخرًا عرضيًا بعد تمكينه على جميع شاشات العرض ، على الرغم من أنه يبقى أن أرى كيف ستزداد سوءًا بشكل مطرد كما تميل.

إذا كانت جميع DE عازمة جدًا على التركيب ، فسيكون من الجيد أن يضمنوا الاستقرار على نطاق واسع في الدقة ، لأنهم جميعًا يعانون في الغالب من نفس المشكلات في القرارات الكبيرة. تعمل القرفة على المنجم مثل تسرب للذاكرة ، قبل إعادة التشغيل / الترقية بعد 90 يومًا أو نحو ذلك ، كنت أرى سطح المكتب القرفة يستخدم عادة 80-90 ٪ من وحدة المعالجة المركزية في معالجة أفضل المتحدثين في htop (لا يبدو أنه خيط حسنًا في جوهره حيث أن لدي 39 خيطًا آخر يمكن استخدامه) ، واستخدم الكثير من الذاكرة ، حوالي 20-30 جيجا بايت (شيء يقال بوجود 128 جيجا بايت في هذا النظام). يجب أن تكون هناك طريقة لاختبار هذا على نطاق واسع ، ويبدو أن نوعًا ما من اختبار الإجهاد يشبه فالجريد. بعد 90 يومًا أو نحو ذلك من الاستخدام هنا ، تكون القرفة دائمًا جاهزة للظهور ، وهذا في عرض البرامج. عادة ما تموت في غضون أسبوع في الأجهزة. كيدي تعاني من نفس الشيء.

لا يقوم معظم الأشخاص بتشغيل شاشات بدقة 11200 × 2160 بشكل شائع ، ولكن هذه شاشات 3x 4k فقط ، والتي أصبحت أكثر شيوعًا وأرخص سعرًا كل يوم ، أو تعدل نفسها وفقًا لذلك. في مرحلة ما ، يحتاج التسميد إلى حساب قرارات مثل هذه ، وأكبر ، مع استقرار طويل الأمد ، أو اكتشاف طريقة للتسوية تناسب الجماهير بشكل أفضل. بدلاً من ذلك ، قم بإعادة رسم مستقر على النوافذ الخاصة بي بدلاً من التذبذب / الشفافية لهم بمرور الوقت. إذا كنت أعرف ما الذي يزعزع استقرار نظامي ، فسأكون سعيدًا بتعطيله.

ما هو إصدار برنامج تشغيل Nvidia الخاص بك؟ إذا كنت تستخدم 390 أو 396 ، فاستخدم 415.25 في Ubuntu PPA .

تبلغ الدقة المجمعة لشاشاتي 8560 × 1440 ، ولا أرى أي تباطؤ في استخدام Cinnamon بمرور الوقت في فروع العلاقات العامة الخاصة بي حاليًا ، في الفترات القليلة التي لا أعيد فيها تشغيل Cinnamon من أجل التطوير.

يضيف خط أنابيب تكوين القوة بعض الكمون. لا أوصي عمومًا باستخدامه ، وإذا كنت تواجه مشكلات في Cinnamon's vsync ، فتأكد من تمكين "السماح بالتقليب" في إعدادات nvidia ، وتعطيل "Sync to vblank". لا تستخدم أي حلول بديلة للسائق مخصصة للسائق 3.8 أو أكبر.

ليس من الواضح بالنسبة لي ما الذي تعتبره تأخرًا - هل المؤشر غير متزامن مع النافذة عند السحب؟ أو كمون الإدخال العام للنوافذ؟ تتأثر هذه الأشياء بأجزاء مختلفة من كود المكون. https://github.com/linuxmint/muffin/pull/397 يحسّن كليهما ، و https://github.com/linuxmint/muffin/pull/392 يحسّن الأخير - الذي كنت أرغب في الوصول إليه في 4.0 ، لكنه يحتاج إلى مزيد من الاختبارات.

تراجع آخر مع الخفقان والتأخر الشديد

دعونا إبقاء هذه القضايا منفصلة، وهناك بالفعل زوجين القضايا المتعلقة الخفقان، وأنا لم وحظ يجري أي أسوأ على 4.0. بالطبع يحتاج إلى الإصلاح ، لكن من الصعب إصلاح شيء لا يمكن إعادة إنتاجه بشكل موثوق.

لذا اعتبارًا من آخر ترقية لي ، فأنا على nvidia 415.25-4 ، لذا في حدود توقعاتك.

لقد قمت بتعيين السماح بالتقليب (لم يتم القيام به من قبل) ، والمزامنة مع تعطيل vblank (يتم ذلك عادةً) ، وفرض خط أنابيب التركيب الكامل على كل شاشة (إعادة تعيين هذه المرة التحقق).

التأخر ، مثل كل ما أفعله. إذا نقرت بين النوافذ ، فإن إعادة الرسم ينتج عنه بعض التأخير ، حيث تتوقف الشاشة لبضع ثوانٍ في كل مرة كما هي مجمدة في مكانها. لقد لعبت دور Overlord على البخار مؤخرًا حيث تقوم بذلك ، بشكل مزعج للغاية أثناء المعركة. لقد تعلمت أن ألاحظ وأستبق عند حدوث ذلك. ينتج عن استخدام سطح المكتب هذا الكشك أيضًا ، وكتابة هذا يؤدي إلى تأخيرات / تقطع متنوعة في النقر بين النوافذ وأثناء الكتابة. كل شيء يتوقف لمدة ثانية أو ثانيتين أثناء الكتابة أو أي نشاط بالماوس أو لوحة المفاتيح بشكل عشوائي.

يميل سحب الأشياء إلى تفاقم المشكلة ، حيث تميل معظم أشياء واجهة المستخدم إلى الغضب وتأخير سطح المكتب ، مما يؤدي إلى توقف الأشياء بصريًا لمدة ثانية أو ثانيتين. سريعًا إلى الأمام 90 يومًا ، ينتج عن هذا توقف لمدة 5 ثوانٍ في كل ما تفعله عندما تقرر الضرب ، أي كل بضع دقائق ، وأحيانًا أقل.

فيما يتعلق بالوميض ، لقد لاحظت أن هذا يحدث في جميع شاشات العرض ، بشكل عشوائي مناطق معينة ، وليس دائمًا نفس الشيء ، ولكن مثل نوع من منطقة الأشباح في الماضي والتي ستبدأ في الوميض لثوانٍ في كل مرة ، وتختفي. هذا عبر جميع الشاشات الثلاثة بدقة 4k ، بعضها مجموعة فرعية صغيرة من شاشة واحدة في كل مرة.

هذه قطعة أثرية أخرى للعرض في البرنامج على ما يبدو ، لكنها غريبة عندما تفعل ذلك. لم أر هذا في إطار عرض الأجهزة ، لكنني فعلت الكثير مع البرامج خلال آخر 90 يومًا أو نحو ذلك باستخدام ذلك. سيء بدرجة كافية تحت الأجهزة بدون أشياء أغرب في البرامج.

لقد قمت بتعيين السماح بالتقليب (لم يتم القيام به من قبل) ، والمزامنة مع تعطيل vblank (يتم ذلك عادةً) ، وفرض خط أنابيب التركيب الكامل على كل شاشة (إعادة تعيين هذه المرة التحقق).

ما كنت أقترحه بشكل أساسي هو إعادة تمكين vsync muffin في الإعدادات -> عام ، وتعطيل خط أنابيب التكوين الكامل للقوة. ستواجه أكبر تأخر إذا تم تمكين كليهما.

من المؤكد أن الخفقان أسوأ في عرض البرامج ، وعند استخدام متغيرات Clutter env معينة يتم استخدامها عند تشغيلها. لم أر هذا يحدث عند التشغيل باستخدام المعلمة nomodeset ، ولكن سيحدث الخفقان إذا تم تحميل برنامج تشغيل Nvidia أثناء استخدام Cinnamon لعرض البرامج. انظر # 7985.

يبدو سلوك "المماطلة" وكأن الخيط يتم حظره بشكل متقطع ، فهل تستخدم أي تطبيقات / ملحقات / ملحقات طرف ثالث؟ تحقق مع gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

أنا مسكت ، لست متأكدًا من مقدار الألم الذي أشعر به تحت قوس لمحاولة أن أكون صادقًا ، أو عادة ما أشعر بالإحباط. أميل إلى الجري مع إصداراتهم وترقيتهم وأدعوهم قليلاً حتى تختفي المشكلة. ليس عبر المراجعات الرئيسية الآن ، 3.x إلى 4.0 الآن. أحاول عدم الانحراف كثيرًا ، فأنا أكسب لقمة العيش من هذا النظام ، بما في ذلك العديد من الشبكات الافتراضية الخاصة ، والأجهزة الافتراضية ، والعديد من نقاط التكامل الأخرى التي أقوم بها.

لا أحصل على الخفقان تحت الأجهزة ، على الرغم من أنه يحصل على تأخير عشوائي على الفور تقريبًا في ذلك. إنه يزداد سوءًا بالفعل أستطيع أن أقول.

نعم ، اضطررت للتوقف عن استخدام Cinnamon مرة أخرى ، كانت تأخيرات إعادة رسم النوافذ تقتلني بعد بضعة أيام فقط ، مما أدى إلى تأخر 5 ثوانٍ في أي نافذة كنت أستخدمها بنشاط. محاولة اللعب مع هذا أمر مستحيل. عادةً ما أعود إلى عرض البرامج حيث يستغرق الأمر عادةً شهورًا للوصول إلى نفس التأخيرات الطويلة في التحديثات ، ولكن عرض البرنامج الآن في 4.0 غير قابل للاستخدام تمامًا.

في حالة جيدة ، لا يزال KDE / Kwin سلة سلة أيضًا ، نفس المشكلة تقريبًا ، لكنني ببساطة لن أجعل النافذة يتم تحديثها على الإطلاق ، وأضطر إلى تصغير النافذة وإعادة تحديدها لإعادة الرسم مع أي تغييرات.

لماذا يعتبر هذا أمرًا صعبًا حقًا بالنسبة للمكوِّنين في أنظمة DE المختلفة؟

لقد تحققت من امتدادات الطرف الثالث ، ولا ، كل ما أملك هو ملحقات القرفة ، ومعظمها افتراضي. عادةً ما كنت أركب cairo-dock واستخدمته للأشياء المخصصة.

لقد أمضيت وقتًا طويلاً في مشاهدة htop و iotop و nvtop و powertop ، وآخرين يحاولون معرفة سبب حدوث ذلك ، لكنني لا أرى أبدًا أي شيء على وجه الخصوص يظهر كخنزير مورد بأي شكل من الأشكال ، خارج سطح المكتب القرفة نفسها ، و xorg بمرور الوقت.

هذا بالطبع هو المكان الذي يصبح فيه غامضًا دائمًا ، ما مقدار xorg أو برامج تشغيل nvidia أو القرفة التي تسيء التصرف؟ لا أعرف أي طرق جيدة لتصحيح هذه الأخطاء داخليًا. أنا آذان مفتوحة إذا كنت تعرف طريقة جيدة لمشاهدة الأجزاء الداخلية لتلك المشاكل ، وخاصة القرفة نفسها لأنها أصبحت بالتأكيد خنزير موارد بمرور الوقت.

تقوم التطبيقات بعملها ، فقط النافذة لا يتم إعادة رسمها خلال لحظات "التأخر" هذه ، لذلك أوافق على أن شيئًا ما يتم حظره ، لكن لا يمكنني معرفة ما هو عليه.

لقد اضطررت إلى التبديل إلى kde لأن التأخر كان يسبب الكثير من الحزن هنا لاستخدامه أخيرًا ، لكن kde لا يبدو وكأنه بطل ، لذا على استعداد لتجربة القرفة مرة أخرى. النعناع بسيط للغاية ، لا يمكنني تحمل جنوم 3 ، لا سيما النسخة المختلة من أوبونتو ، لذلك أستمر في العودة إلى القرفة على الرغم من المشاكل. أود حقًا المساعدة في إصلاحها إذا كان ذلك ممكنًا ، فمن الواضح أنني لست الوحيد من خلال هذا الموضوع.

أشعر بالفضول قليلاً لما حدث للأشخاص الآخرين الذين رأوا هذا ...

لماذا يعتبر هذا أمرًا صعبًا حقًا بالنسبة للمكوِّنين في أنظمة DE المختلفة؟

من الصعب القيام بتحسين التركيب ، ويتطلب الكثير من التجربة والخطأ. إنه ببساطة ليس بالأمر السهل العمل عليه.

كل ما كان لدي هو ملحقات القرفة ، ومعظمها الافتراضي. عادةً ما كنت أركب cairo-dock واستخدمته للأشياء المخصصة.

خاصة؟ ما هي الامتدادات المستخدمة؟ هذا تفصيل مهم. نحتاج إلى معلومات يمكن أن تساعد في إعادة إنتاج المشكلة ، وليس جدارًا من النصوص الصاخبة حول التركيب. شكر!

كان هناك مكتب صغير بدا ممكّنًا ، bbcwx ، تطبيق صغير خاص بالطقس ، لكنني لم أر أي علامة على وجوده أو تشغيله مسبقًا.

[ user @ host ~] $ gsettings الحصول على تطبيقات org.cinnamon الممكّنة
[' panel1: left: 0: [email protected] : 0'، ' panel1: left: 1: [email protected] : 1'، ' panel1: left: 2: [email protected] : 2 '،' panel1: left: 3: [email protected] : 3 '،' panel1: right: 0: [email protected] : 4 '،' panel1: right: 1: [email protected] : 5 '،' panel1: right: 2: [email protected] : 6 '،' panel1: right: 3: [email protected] : 7 '،' panel1: right: 4: [email protected] : 8 '،' panel1: right: 5: [email protected] : 9 '،' panel1: right: 6: [email protected] : 10 '،' panel 1: right: 7: [email protected] : 11 ' ، ' panel1: right: 8: [email protected] : 12'، ' panel1: right: 9: [email protected] : 13'، ' panel 1: right: 10: [email protected] : 14 ']
[ user @ host ~] $ gsettings الحصول على مكاتب صغيرة من org.cinnamon
[" [email protected] : 1: 50: 50"]
[ user @ host ~] $ gsettings الحصول على امتدادات org.cinnamon الممكنة @ as []

إنني أدرك بالفعل أن التعامل مع التركيب هو عمل معقد ، لذلك لا أقصد التقليل من أهمية الجهد ، وأنا بالتأكيد أقدرهم في أعماقي ، لكن التركيب موجود في كل DE أستخدم الحلقة الأضعف في كل شيء تحت نظام Linux. حتى في Windoze ، يمكن أن تكون Aero سلة للتركيب وجدتها في استخدامي المحدود خارج الصندوق على كمبيوتر محمول dell. من المذهل عدد الجهود الفريدة التي يبدو أنها أخطأت في فهم هذا الأمر ، لذلك أتساءل فقط عن سبب ضرورة ذلك عندما يبدو من المستحيل تحقيقه بشكل جيد بما فيه الكفاية. يبدو أنه يجب أن يكون هناك طريقة أفضل.

حسنًا ، لذلك إذا تم تمكين bbcwx ولكن لم يتم عرضه ، فقد يكون سلوكًا سيئًا. هناك أيضًا عدد قليل من العلاقات العامة التي فتحتها والمخصصة لـ 4.0.x والتي قد تؤثر على الأداء ، مثل # 8180. لست متأكدًا من موعد دمج هذا الشخص ولكن يجب على الجميع استخدامه أو التبديل إلى GWL.

أتفهم الإحباط - ولهذا السبب بدأت في تعلم لغة C حتى أتمكن من تحسين الكعك ، لكن ليس هناك الكثير الذي يمكنني فعله باستثناء العلاقات العامة المفتوحة (التي كنت أفعلها). لقد تأخرت الرسومات على نظام Linux بشكل عام لفترة طويلة ، وبدأت مؤخرًا في اللحاق بالركب بعد بعض التغييرات الكبيرة (مثل البروتون). هناك الكثير من العمل الذي يجب القيام به ، وهدفي هو جعل الكعك سريع الاستجابة مثل DWM في Windows 10.

لا أتذكر تمامًا تمكينه ، لذلك لابد أنه كان شيئًا عشوائيًا ونسيًا. سأزيله ، إذا كان بإمكاني معرفة كيف.

أنا أستخدم نظام لينكس منذ عام 2006 بدوام كامل ، وأتذكر قبل / بعد التركيب ، وكانت الحياة أسهل بكثير من قبل. لقد تعاملت مع مشاكل Ubuntu و Compiz لسنوات عندما بدأ ذلك ، لقد دفعني إلى KDE ، لاحقًا إلى Mate / Cinnamon ، والآن ذهابًا وإيابًا مؤخرًا الذي تمتصه أقل.

حتى الآن كان الانتقال من 3.x إلى 4.0 هو الأسوأ مع Cinnamon ، ولكن يبدو أنهم جميعًا يعانون من بعض تسرب الموارد المتأصل الذي يزداد سوءًا بمرور الوقت. نظرًا لأنهم جميعًا يفعلون ذلك ، فأنا غالبًا ما أظن أنه مكون منخفض المستوى ، مثل برنامج تشغيل xorg أو nvidia الذي يتسبب في زعزعة الاستقرار بين جميع أجهزة DE ، ولكن لا توجد طريقة لمعرفة ذلك. وهكذا أبدأ بـ DE ، لكنني أشاهد أيضًا العديد من القمة لمحاولة معرفة سبب تأخيرات الرسوم هذه ، حتى الآن دون جدوى.

أميل إلى اتباع ترقيات pacman العادية لمحاولة سحب التحديثات من الخارج بشكل نظيف ، ولست متأكدًا من كيفية تجربة إصدارات الكعك التالية في القوس أو سأفعل.

ولدي أيضا هذه المسألة. انظر لقطة لمواصفاتي. لدي حتى 128 جيجابايت من ذاكرة الوصول العشوائي: https://gyazo.com/1f0443df15097949a2314bebba6d12db

حللت الانتقال إلى XFCE> <(لذا لم تحل في القرفة)

zenfulcoder أين تستخدم ذاكرة الوصول العشوائي h * K التي

@ خطر 89 نعم أحب XFCE ، لقد تحولت للتو إلى Cinnamon بعد سنوات من XFCE. أحببت Cinnamon لسطح المكتب الحديث وتكاملها. تمتص أنه يتطلب OpenGL للتشغيل.

حسنًا ، لقد دعمت لوحة بلدي ، لذلك وضعتها في XD. لكن بهذه الطريقة ، بالنسبة للعمل ، لم أنفد أبدًا. غير محدود في الأساس. لكنها ما زالت تسير ببطء في القرفة !!

zenfulcoder مرحبا بكم حيث يوجد عنق الزجاجة. بشكل صحيح ليس بسبب حجم ذاكرتك ، لا يزال من الممكن أن تكون سرعة الذاكرة / زمن الوصول وأي شيء لا. وباقي أجهزة الكمبيوتر (الأقراص / اللوحة الأم / hm .. الخ).

ومع ذلك ، من المحتمل ألا يتعلق الأمر بالمواصفات الخاصة بك على الإطلاق كما ترى في القسم أعلاه. هناك بعض الأخطاء في أي من مشغلات الفيديو ، Xorg أو أي شيء في تلك المنطقة.

@ danger89 إنها بالتأكيد مشكلة مع Cinnamon. قرأت أن الإصدار 4 قد يكون أفضل ، لكنه غير مستقر بما يكفي لدبيان حتى الآن.