قياس زمن استجابة المدخلات على لينكس: Wayland أسرع من X11 بأدلة عتادية

أبرز النقاط

• Wayland الأصلي يتفوق على X11 وXWayland في زمن الاستجابة الفعلي
• VRR (معدل التحديث المتغير) يحتاج ضبطاً دقيقاً لتجنب زيادة الكمون
• إضافة dxvk-low-latency تمتص تذبذبات أوقات الإطارات وتمنع تراكم طابور الرندر

منذ إطلاق Steam Deck وانتشار Proton، انتقل آلاف اللاعبين التنافسيين إلى لينكس بحثاً عن إطارات أعلى وزمن استجابة أقل. لكن السؤال الذي يتكرر في كل منتدى: هل Wayland فعلاً أبطأ من X11؟ وهل إعدادات VRR وDXVK تُحدث فرقاً حقيقياً أم مجرد وهم؟ مطوّر ألماني قرر إنهاء الجدل ببناء جهاز قياس فعلي.

كيف يُقاس زمن الاستجابة من النقر إلى الشاشة؟

الفكرة بسيطة لكن التنفيذ يحتاج دقة: مستشعر ضوئي يُثبَّت على الشاشة ويتصل عبر USB بالحاسوب. عند محاكاة نقرة الفأرة، يبدأ المؤقت ويتوقف لحظة رصد المستشعر لتغيّر السطوع. الناتج هو زمن الاستجابة الكامل للنظام (end-to-end latency) — من الإدخال البشري حتى وصول البكسل إلى العين.

صاحب المشروع درس تصاميم مفتوحة المصدر مثل OSLTT وm2p-latency وOpen-Source-LDAT، ثم بنى نسخته الخاصة مستخدماً متحكمات دقيقة ومضخمات transimpedance وتصميم غلاف مخصص. الكود والعتاد والبيانات الخام متاحة على GitHub.

ما الذي اختبره بالتحديد؟

• X11 مقابل Wayland الأصلي (Native Wayland عبر PROTON_ENABLE_WAYLAND=1)
• XWayland كحالة مرجعية إضافية
• VRR (معدل التحديث المتغير) مفعّل ومعطّل
• dxvk-low-latency المدمج حديثاً في proton-cachyos عبر PROTON_DXVK_LOWLATENCY=1
• وضع Flip (direct scanout) مقابل وضع Blit (compositing) على KDE Plasma

اللعبة المستخدمة هي Diabotical، عنوان DirectX 11 تنافسي يُشغَّل عبر Heroic وProton. أمر مخفي يربط النقر بعرض مربع أبيض كبير، ما يُنتج فرقاً واضحاً في السطوع يرصده المستشعر بدقة.

لماذا يُعدّ XWayland أبطأ من Wayland الأصلي؟

XWayland هو طبقة توافق تُشغّل تطبيقات X11 داخل بيئة Wayland. كل إطار يمر بخطوة إضافية: التطبيق يرسم إلى X11، ثم XWayland ينسخ المحتوى إلى Wayland. هذه النسخة تضيف كموناً ملموساً. الاختبارات أكدت ما كان اللاعبون يحسّونه: Wayland الأصلي يتفوق، وXWayland يقترب من X11 في البطء.

ما دور dxvk-low-latency في تقليل الكمون؟

إضافة dxvk-low-latency التي طوّرها netborg تعمل كمنظّم إطارات (frame pacer). وظيفتها امتصاص تذبذبات أوقات الإطارات ومنع تراكم الإطارات في طابور الرندر، وهو السبب الرئيسي للشعور بـ"ثقل" التحكم حتى مع FPS مرتفع. المشروع أُدمج رسمياً في حزمة proton-cachyos ويُفعَّل بمتغير بيئة واحد.

في الاختبارات ذات المشهد الثابت، لم تظهر تذبذبات لأن السيناريو كان محدوداً بالمعالج (CPU-bound) بالكامل. لكن المطوّر أضاف حالات اختبار غير محدودة الإطارات لإظهار عمل المنظّم في ظروف أقرب للّعب الحقيقي.

هل VRR يزيد أم يقلل زمن الاستجابة؟

معدل التحديث المتغير (FreeSync/G-Sync) يزيل التمزق ويُنعّم الحركة، لكنه ليس مجانياً. الاختبارات أُجريت مع VRR مفعّل ومعطّل، ومع إعدادات dxvk مخصصة لكل حالة. الإعداد الموصى به يشمل تحديد dxvk.framePace إلى low-latency-vrr-500 مع إيقاف تداخل إطارات المعالج.

كيف تتأكد أن لعبتك تعمل في وضع Flip؟

على KDE Plasma، وضع Flip (direct scanout) يتجاوز المركّب ويرسل الإطار مباشرة إلى الشاشة. للتحقق: افتح KWin Debug Console، فعّل showcompositing في تبويب Effects، ثم شغّل اللعبة في وضع ملء الشاشة. إن لم يظهر إطار أحمر حول الحواف، فاللعبة في وضع Flip.

الأسئلة الشائعة

هل Wayland أفضل من X11 للألعاب التنافسية على لينكس؟

نعم، الاختبارات العتادية تُظهر أن Wayland الأصلي يتفوق في زمن الاستجابة، بشرط تشغيل اللعبة عبر Native Wayland وليس XWayland.

كيف أفعّل dxvk-low-latency في Proton؟

أضف متغير البيئة PROTON_DXVK_LOWLATENCY=1 قبل تشغيل اللعبة، أو عدّل إعدادات الإطلاق في Steam/Heroic.

هل VRR يزيد زمن الاستجابة؟

يعتمد على الإعدادات. بدون ضبط دقيق لـ dxvk.framePace، قد يضيف كموناً طفيفاً. الإعداد الموصى به هو low-latency-vrr-500.

ما الفرق بين وضع Flip وBlit على Wayland؟

Flip يتجاوز المركّب ويرسل الإطار مباشرة للشاشة (أقل كموناً)، بينما Blit يمر عبر طبقة التركيب.

هل يمكنني بناء جهاز قياس الكمون بنفسي؟

نعم، المشروع مفتوح المصدر على GitHub ويشمل المخططات والكود والتصميمات الثلاثية الأبعاد للغلاف.