اختبار تخطي الإطارات

كيف تستخدم هذا الاختبار

1. انقر على «بدء الاختبار» ودعه يعاير.

   تحدد الثانية الأولى أو نحوها فاصل التحديث الفعلي لديك تلقائيًا — دون الحاجة إلى إخباره بمعدل Hz لشاشتك.

2. دعه يعمل من 15 إلى 30 ثانية على الأقل.

   قد يُظهر التشغيل القصير صفر تخطٍّ بمحض الصدفة؛ أما التشغيل الأطول فيعطي صورة أصدق.

3. راقب الرسم البياني المباشر بحثًا عن الارتفاعات الحادة.

   الخط المستوي قرب زمن الإطار المتوقع دليل على أداء سليم؛ أما الارتفاعات الحادة فهي حالات تخطٍّ تُرصد لحظة حدوثها.

4. أغلق علامات التبويب الأخرى والبرامج الثقيلة إن تكرر التخطي.

   لا يرى هذا الاختبار إلا التأخيرات في جانب المتصفح — والنظام المشغول سبب شائع يمكن علاجه.

5. استخدم الكاميرا لتأكيد سلوك اللوحة نفسها.

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

قيمة 1% low وإيقاع التوقفات: ما تقوله الأرقام الإضافية

تجد تحت الرسم ثلاث قراءات لا يوفّرها عدّاد التخطي البسيط. متوسط FPS هو الرقم الذي تتوقف عنده معظم الأدوات، وهو يُخفي تقريبًا كل ما هو مهم. أما 1% low فهو متوسط معدل الإطارات لأبطأ 1% من الإطارات، و0.1% low هو الشيء نفسه لأبطأ إطار من كل ألف. في شاشة 60 Hz سليمة تقع القيم الثلاث ضمن بضعة بالمئة من بعضها. فإذا كان المتوسط 59.8 وقيمة 1% low تساوي 31، فهذا يعني أن الشاشة تتعثر لإطار أو إطارين كل بضع ثوانٍ، وأن المتوسط أكبر من أن يُظهر ذلك.

العنصر الثالث هو إيقاع التوقفات. في كل مرة يصل فيها إطار متأخرًا يسجّل الاختبار وقت حدوث ذلك، ثم ينظر في الفواصل بين التوقفات. فإذا تكررت الفواصل بتباعد متقارب (مثل 4.0 ثوانٍ و4.1 و3.9) فهذا يشير إلى شيء يعمل بمؤقّت: عميل مزامنة، أو فحص مجدول، أو أداة RGB أو مراقبة تستعلم عن العتاد، أو حالة توفير طاقة تدخل في العمل. أما الفواصل المتفرقة فتعني عادةً حِملًا عاديًا على النظام. ويضيف المخطط الشريطي معلومة أخرى: الإطارات التي تأخرت لكن ليس بما يكفي لتُحسب تخطيًا (من 1.25 إلى 1.5 ضعف الفاصل المعتاد). وسلسلة طويلة منها تُشعِر بارتجاج خفيف حتى لو أظهر عدّاد التخطي صفرًا.

للاستخدام: أغلق ما تستطيع إغلاقه، وابدأ الاختبار، واترك التبويب ظاهرًا دون لمس، ودعه يعمل 20 ثانية على الأقل (والدقيقة أفضل). ثم أوقف الاختبار. يلخّص سطر الحكم التشغيل عندئذٍ. تحتاج قيمة 1% low إلى نحو 100 إطار، وقيمة 0.1% low إلى نحو 1000 (نحو 17 ثانية عند 60 Hz و7 عند 144 Hz)، ويحتاج فحص الإيقاع إلى أربعة توقفات على الأقل قبل أن يقول شيئًا. بعد ذلك أعد التشغيل مع إغلاق برنامج مشتبه به. فإذا اختفى الإيقاع فقد وجدت المؤقّت المسؤول.

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

تخطي الإطارات على شاشة 60 هرتز: قراءة نتيجة 30 ثانية

لنفترض أنك شغّلت الاختبار 30 ثانية على شاشة بتردد 60 هرتز. يظهر المعدل المكتشف 60 هرتز، فيستغرق الإطار العادي نحو 16.7 ms. عند الضغط على «إيقاف الاختبار» يقول سطر الحالة: «رُصدت 18 حالة تخطٍّ عبر 1782 إطار (1.01%). أطول توقف: 66.7 ms.» الزمن 66.7 ms يساوي أربعة فواصل عادية، أي أن كل توقف طويل كلّف ثلاثة إطارات. ويضيف الحكم «يبدو المتوسط (59 fps) جيدًا، لكن قيمة 1% low هي 30 fps. وهذه الفجوة تظهر تعثرًا مرئيًا.» ويقول سطر الإيقاع «إيقاع التوقفات: منتظم. يحدث توقف واحد تقريبًا كل 5.0 ث (أي كل 300 إطارًا تقريبًا) على امتداد التوقفات المسجّلة وعددها 6. يبدو هذا كشيء يعمل بمؤقّت.» ستة توقفات، كلٌّ منها أضاع ثلاثة إطارات، هي أصل الرقم 18.

التوقف الذي يتكرر كل خمس ثوانٍ بالضبط يكون غالبًا بسبب مؤقّت. لنفترض أنك فتحت مدير المهام فوجدت عميل مزامنة سحابية يستيقظ كل خمس ثوانٍ. توقفه مؤقتًا وتعيد الاختبار 30 ثانية. الآن يقول سطر الحالة «لم تُرصد أي حالة تخطٍّ عبر 1800 إطار» ويبدأ الحكم بـ«سلس.» مع قيمة 1% low ضمن 10% من المتوسط. الشاشة نفسها والمتصفح نفسه، وبرنامج واحد أقل في الخلفية.

ليس كل تخطٍّ مشكلة. لنفترض أن إحدى التجارب أظهرت «رُصدت 1 حالة تخطٍّ عبر 1800 إطار (0.06%). أطول توقف: 33.3 ms.» وأن الحكم جاء «مستقر في معظمه. قيمة 1% low تبلغ 57 fps مقابل متوسط 60 fps، وعدد حالات التخطي 1.» هذا إطار واحد ضائع في نصف دقيقة، ربما بسبب التبديل بين النوافذ أو لأن الصفحة كانت تنهي تحميل آخر مواردها لحظة الضغط على «بدء الاختبار». أعد التشغيل دون أن تلمس شيئًا. فإن خرجت النتيجة سليمة فتجاهلها.

كيف يعمل هذا الاختبار فعليًا

يعيد كل استدعاء لـ requestAnimationFrame طابعًا زمنيًا، ويقيس هذا الاختبار الفجوة بين الطوابع المتتالية بدل افتراض رقم ثابت. وفي أول بضع وعشرين إطارًا يجمع هذه الفجوات ويأخذ وسيطها لتحديد فاصل التحديث الفعلي لديك — نحو 16.7ms على شاشة 60Hz، و6.9ms على 144Hz، وهكذا — ولهذا يعمل بالطريقة نفسها أيًّا كان تصنيف شاشتك، دون أن تحتاج إلى إدخال شيء.

بعد نافذة المعايرة هذه، تُسجَّل أي فجوة تأتي أطول بوضوح من الفاصل المتوقع — أكثر من 1.5 ضعفه — على أنها تخطٍّ، ويُحسب عدد الإطارات المتخطاة من مقدار زيادة تلك الفجوة عن المتوقع. وتتقدم العلامة المرقّمة أعلاه بواحد في كل إطار يرسمه المتصفح فعليًا، وهذا ما يجعل تصويرها ذا معنى: فالتخطي الحقيقي يظهر رقمًا مكررًا أو مفقودًا، لا مجرد رقم على الشاشة.

ما لا يستطيع هذا الاختبار رؤيته

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

أما ما لا يستطيع رؤيته فهو التخطي الذي يحدث في مراحل أبعد من المسار، داخل الشاشة نفسها. فقد تكرر وحدة تحجيم الصورة في اللوحة نفسها إطارًا سلّمه المتصفح بشكل صحيح تمامًا وفي وقته — ومن وجهة نظر المتصفح لم يحدث أي خطأ، ومع ذلك تتقطع الشاشة. ولا يستطيع أي شيفرة JavaScript يعمل في علامة تبويب المتصفح رصد ذلك، لأن المتصفح يكون قد أنهى مهمته حين يحدث تخطٍّ كهذا.

تأكيد التخطي على مستوى اللوحة بالكاميرا

الطريقة العملية لفحص ما تفعله شاشتك فعلًا، بمعزل عمّا يعرضه هذا الاختبار، هي صورة ببطء الغالق. اضبط سرعة غالق كاميرا الهاتف على أبطأ من فاصل تحديث واحد — أي أبطأ من نحو 1/60 من الثانية لشاشة 60Hz — ثم صوّر العلامة المرقّمة أثناء تشغيل الاختبار.

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

أسباب تخطي الإطارات

في جانب المتصفح: معالج مشغول بشيء آخر، أو علامات تبويب أو برامج في الخلفية تتنافس على الموارد، أو توقف لجمع المهملات يعطّل الخيط الرئيسي للحظات، أو وحدة معالجة رسومات تعجز عن مواكبة عملية التركيب — وبرنامج تشغيل رسومات قديم يزيد احتمال هذا الأخير، لذا يستحق الأمر التأكد من أنك تستخدم أحدث إصدار من NVIDIA أو AMD أو Intel. يمكن لأي من هذه الأسباب أن يجعل المتصفح يفوّت نافذته لتسليم إطار جديد، وهو ما سيرصده هذا الاختبار بشكل صحيح.

وفي جانب الشاشة: كابل أو منفذ لا يدعم دقتك ومعدل تحديثك المختارين معًا بالكامل (مثال شائع دقة 4K بمعدل 120Hz عبر منفذ لا يدعم إلا 4K بمعدل 60Hz، وقد يتراجع بصمت أو يتخطى إطارات)، أو معدل تحديث مرفوع بالأوفركلوك فوق ما تستطيع اللوحة تحمّله بثبات، أو معالجة صورة قوية مثل تنعيم الحركة تتداخل مع توقيت الإطارات. وهذه الأنواع تحتاج إلى طريقة الكاميرا المذكورة أعلاه للتأكد منها بشكل صحيح — فهذه المعالجة نفسها سبب شائع أيضًا للضبابية الإضافية التي يفحصها اختبار الظلال (Ghosting).

هذا الاختبار مقابل اختبار معدل التحديث

يجيب هذان الاختباران عن سؤالين مختلفين ويعملان معًا بشكل جيد. يخبرك اختبار معدل التحديث بالمعدل الذي تعمل به شاشتك حاليًا — هل تعمل فعلًا بـ 144Hz، أم تراجعت بصمت إلى 60؟ أما هذا الاختبار فيفترض أن المعدل الذي يكتشفه صحيح، ويسأل بدلًا من ذلك: هل يصل كل إطار بذلك المعدل في موعده فعلًا، أم أن بعضها يُتخطى أو يتكرر في الطريق؟ وقد تنجح الشاشة في أحد الاختبارين وتفشل في الآخر.

المزيد من الأدوات على ProDeviceTest

تسليم الإطارات جزء واحد من جودة الحركة الإجمالية. وتغطي هذه الأدوات الباقي.

• اختبار معدل التحديث — قِس ما تُخرجه شاشتك فعليًا الآن
• اختبار الظلال (Ghosting) — افحص ضبابية الحركة والأثر الباقي بجسم متحرك
• اختبار HDR — افحص HDR والنطاق اللوني الواسع وتفاصيل الظلال والإضاءات العالية
• جميع اختبارات الشاشة — الفئة كاملة