نحو مقياس سلاسة الرسوم المتحركة

تعرَّف على كيفية قياس الرسوم المتحركة وكيفية التفكير في إطارات الرسوم المتحركة وسلاسة الصفحة بشكل عام.

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

نودّ مشاركة بعض الإنجازات الأخيرة وتقديم إرشادات ملموسة حول الأدوات ومناقشة أفكار حول مقاييس سلاسة الرسوم المتحركة في المستقبل. يسرّنا دائمًا معرفة ملاحظاتك.

ستتناول هذه المشاركة ثلاثة مواضيع رئيسية:

• نظرة سريعة على الصور المتحركة وإطاراتها
• أفكارنا الحالية حول قياس سلاسة الرسوم المتحركة بشكل عام
• إليك بعض الاقتراحات العملية التي يمكنك الاستفادة منها في أدوات المختبر اليوم.

ما هي الرسوم المتحركة؟

تُضفي الرسوم المتحركة الحيوية على المحتوى. من خلال تحريك المحتوى، خاصةً استجابةً لتفاعلات المستخدمين، يمكن أن تجعل الصور المتحركة التجربة أكثر طبيعية ومفهومة وممتعة.

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

كيف تعمل الصور المتحركة؟

في ما يلي ملخّص سريع عن مسار العرض: يتألف من بضع مراحل متسلسلة:

1. النمط: احتساب الأنماط التي تنطبق على العناصر
2. التنسيق: يمكنك إنشاء الشكل الهندسي والموقع لكل عنصر.
3. الطلاء: يمكنك ملء ملف bmp بكل وحدات البكسل لكل عنصر في الطبقات.
4. مركب: ارسم الطبقات على الشاشة.

على الرغم من أنّ هناك العديد من الطرق لتحديد الصور المتحركة، إلا أنّها تعمل جميعًا بشكل أساسي من خلال أحد الإجراءَين التاليَين:

• تعديل خصائص التنسيق
• تعديل سمات الطلاء
• تعديل خصائص المزيج

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

على الرغم من أنّه قد يكون من المفيد إضافة مؤثرات متحركة إلى عناصر التنسيق، إلا أنّ هناك تكاليف متعلّقة بإجراء ذلك، حتى إذا لم تكن هذه التكاليف واضحة على الفور. يجب تحديد الرسوم المتحرّكة من حيث تغييرات المواقع المركبة كلما أمكن ذلك.

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

ما هي إطارات الصور المتحركة؟

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

تعرِض هذه السمة التحديثات بعد فاصل زمني معيّن، وبالتالي يتم تجميع التعديلات المرئية. يتم تعديل محتوى العديد من الشاشات في فواصل زمنية ثابتة، مثل 60 مرة في الثانية (أي 60 هرتز). يمكن أن توفّر بعض الشاشات الحديثة معدّلات تحديث أعلى (أصبح معدّل التحديث من 90 إلى 120 هرتز شائعًا). غالبًا ما يمكن لهذه الشاشات التكيف بشكل نشط بين معدّلات التجديد حسب الحاجة، أو حتى تقديم معدّلات عرض صور متغيّرة بالكامل.

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

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

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

ما هي العوامل التي تؤثّر في إطارات الرسوم المتحركة؟

يمكن لمطوّري الويب التأثير بشكل كبير في قدرة المتصفّح على عرض التعديلات المرئية وتقديمها بسرعة وبكفاءة.

إليك بعض الأمثلة:

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

ولكن كيف يمكنك معرفة متى لم يظهر لقطة متحركة خلال الموعد النهائي لها وتسبب في عدم عرض لقطة؟

من الطرق الممكنة استخدام requestAnimationFrame() الاستطلاع، ولكنّ له عدة سلبيات. يُعلم العنصر requestAnimationFrame()، أو "rAF"، المتصفّح بأنّك تريد تنفيذ صورة متحركة ويطلب فرصة لتنفيذ ذلك قبل مرحلة الرسم التالية في مسار المعالجة. إذا لم يتمّ استدعاء وظيفة الاستدعاء في الوقت المتوقّع، يعني ذلك أنّه لم يتمّ تنفيذ عملية طلاء، وتمّ تخطّي إطار واحد أو أكثر. من خلال الاستطلاع ومحاولة معرفة عدد مرات استدعاء rAF، يمكنك احتساب نوع من مقياس "اللقطات في الثانية" (FPS).

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

لا يُنصح باستخدام الاستطلاعات من النوع requestAnimationFrame() لعدة أسباب:

• على كل نص برمجي إعداد حلقة طلب المعلومات الخاصة به.
• يمكن أن يؤدي ذلك إلى حظر المسار الحرج.
• حتى إذا كان الاستطلاع في rAF سريعًا، يمكن أن يمنع requestIdleCallback() من إمكانية جدولة وحدات وقت الاستراحة الطويلة عند استخدامها بشكل مستمر (الوحدات التي تتجاوز إطارًا واحدًا).
• وبالمثل، يمنع عدم توفّر فترات طويلة من عدم النشاط المتصفّح من جدولة مهام أخرى تستغرق وقتًا طويلاً (مثل جمع المهملات لفترة أطول وغيرها من المهام التي تعمل في الخلفية أو المهام التوقّعية).
• في حال تفعيل ميزة الاستطلاع وإيقافها، ستفوتك الحالات التي تم فيها تجاوز ميزانية اللقطات.
• سيُبلغ الاستطلاع عن نتائج إيجابية خاطئة في الحالات التي يستخدم فيها المتصفّح وتيرة تعديل متغيرة (على سبيل المثال، بسبب حالة الطاقة أو مستوى الرؤية).
• والأهم من ذلك، لا تلتقط هذه الميزة جميع أنواع التحديثات المتحرّكة.

يمكن أن يؤثّر العمل الزائد في سلسلة التعليمات الرئيسية في إمكانية رؤية إطارات الصور المتحركة. اطّلِع على مثال على التنقّل غير السلس لمعرفة كيف يؤدي استخدام رسوم متحركة مستندة إلى رسومات معدل عرض اللقطات المتغيرة (rAF) إلى إسقاط اللقطات وانخفاض عدد عمليات الاستدعاء لرسومات معدل عرض اللقطات المتغيرة وانخفاض عدد اللقطات في الثانية، وذلك بعد أن يصبح هناك الكثير من العمل على الخيط الرئيسي (مثل التنسيق).

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

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

يعرض الفيديو أعلاه صفحة تُضيف بشكل دوري مهام طويلة إلى السلسلة الرئيسية. تؤدي هذه المهام الطويلة إلى إيقاف قدرة الصفحة على تقديم أنواع معيّنة من التحديثات المرئية، ويمكنك في أعلى يمين الشاشة ملاحظة انخفاض مفاجئ في عدد اللقطات في الثانية من requestAnimationFrame() إلى 0.

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

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

بالنسبة إلى إطارات الصور المتحركة، لا تكون القصة بهذه البساطة.

إطارات الرسوم المتحركة: آخر الأخبار المهمة

يوضّح المثال أعلاه أنّ هناك المزيد من التفاصيل في القصة غير requestAnimationFrame().

متى تكون تعديلات الصور المتحركة وإطاراتها مهمة؟ في ما يلي بعض المعايير التي نفكر فيها ونريد الحصول على ملاحظات بشأنها:

• تعديلات على سلسلة التعليمات الرئيسية وسلسلة تعليمات أداة الدمج
• عدم توفّر تعديلات الطلاء
• رصد الصور المتحركة
• الجودة مقابل الكمية

تعديلات على سلسلة التعليمات الرئيسية وسلسلة تعليمات أداة الدمج

تعديلات إطارات الصور المتحركة ليست منطقية. لا يمكن أن يتم فقط إسقاط اللقطات بالكامل أو عرضها بالكامل. هناك العديد من الأسباب التي قد تؤدي إلى عرض جزئي لإطار من الرسوم المتحركة. بعبارة أخرى، يمكن أن يتضمّن التطبيق في الوقت نفسه بعض المحتوى القديم وبعض التعديلات المرئية الجديدة التي يتم عرضها.

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

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

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

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

عدم توفّر تعديلات الطلاء

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

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

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

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

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

متى يكون معدل نقل اللقطات مهمًا؟

رصد الصور المتحركة

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

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

حتى مع استخدام requestAnimationFrame()، لا يمكنك دائمًا افتراض أنّ كل طلب رسوم متحركة للواقع المعزّز يؤدي بالضرورة إلى إجراء تعديل مرئي أو إنشاء صورة متحركة. على سبيل المثال، لا يُفترض أن يؤثّر استخدام الاستطلاع rAF لتتبُّع معدّل عرض اللقطات (كما هو موضّح أعلاه) في قياسات السلاسة لأنّه ليس هناك تعديل مرئي.

الجودة مقابل الكمية

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

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

أو قد تكون لعبة تستخدِم <canvas> (ربما باستخدام تقنيات مثل canvas خارج الشاشة ل ضمان معدّل عرض ثابت للإطارات) سلسة من الناحية الفنية تمامًا من حيث إطارات الرسوم المتحركة، مع تعذُّر تحميل مواد عرض اللعبة العالية الجودة في المشهد أو عرض عناصر المعالجة.

وبطبيعة الحال، يمكن أن يتضمّن الموقع الإلكتروني بعض الصور المتحركة السيئة جدًا. 🙂

أعتقد أنّها كانت رائعة في وقتها.

حالات إطار صورة متحركة واحد

بما أنّه قد يتم عرض اللقطات جزئيًا أو قد يتم حذف اللقطات بطرق لا تؤثّر في السلاسة، بدأنا نعتبر أنّ كل لقطة لها نتيجة اكتمال أو سلاسة.

في ما يلي مجموعة الطرق التي نتّبعها لتفسير حالة ملف واحد للصورة المتحركة، مرتبة من الحالة الأفضل إلى الحالة الأسوأ:

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

تجميع كل العناصر معًا: مقياس "النسبة المئوية للّقطات المفقودة"

على الرغم من أنّه قد يكون من الضروري أحيانًا التوغّل في حالة كلّ إطار من إطارات الصور المتحركة، إلا أنّه من المفيد أيضًا منح نتيجة سريعة "بنظرة سريعة" للتجربة.

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

يجب أن ينتقل النموذج الذهني من:

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

ما يهمّ هو: نسبة الوقت الذي تنتظر فيه حصولك على التحديثات المهمة. ونعتقد أنّ هذا يتوافق مع الطريقة الطبيعية التي يواجه بها المستخدمون سلاسة محتوى الويب في الممارسة العملية. حتى الآن، كنا نستخدم ما يلي كأحد المجموعات الأولية للمقاييس:

• متوسط النسبة المئوية للإطارات التي تم إسقاطها: لجميع لقطات الرسوم المتحركة غير المتوقفة خلال المخطط الزمني بأكمله
• أسوأ نسبة لقطات تم إسقاطها: يتم قياسها على مدار نوافذ زمنية متحركة مدّتها ثانية واحدة.
• النسبة المئوية التسعون من نسبة اللقطات المفقودة: يتم قياسها على مدار ثانية واحدة باستخدام نوافذ زمنية متحركة.

يمكنك العثور على هذه النتائج في بعض أدوات مطوّري برامج Chrome اليوم. على الرغم من أنّ هذه المقاييس تركّز فقط على إجمالي معدل نقل اللقطات، فإنّنا نُقيّم أيضًا عوامل أخرى، مثل وقت استجابة اللقطة.

جرِّب ذلك بنفسك في أدوات المطوّرين.

شاشة معلومات أداء السيارة

يحتوي Chromium على شاشة معلومات أداء رائعة مخفية خلف علامة (chrome://flags/#show-performance-metrics-hud). يمكنك العثور فيها على علامات قياس أداء حية لعناصر مثل "مؤشرات أداء الويب الأساسية"، بالإضافة إلى بعض التعريفات التجريبية لسلاسة الرسوم المتحركة استنادًا إلى نسبة اللقطات المفقودة بمرور الوقت.

إحصاءات العرض للإطارات

فعِّل "إحصاءات عرض اللقطات" في "أدوات المطوّر" من خلال إعدادات العرض لعرض عرض مباشر لإطارات الرسوم المتحركة الجديدة، التي يتم ترميزها حسب اللون للتمييز بين التعديلات الجزئية والتعديلات التي تم إسقاط اللقطات بالكامل فيها. يتم تسجيل عدد اللقطات في الثانية للّقطات المعروضة بالكامل فقط.

أداة "عرض اللقطات" في تسجيلات الملف الشخصي للأداء في أدوات مطوّري البرامج

منذ فترة طويلة، تتضمّن panel DevTools (لوحة أدوات مطوري البرامج) المخصّصة للأداء viewer (أداة عرض). ومع ذلك، أصبح هذا الإصدار غير متوافق إلى حدٍ ما مع آلية عمل مسار التقديم الحديث. لقد أجرينا الكثير من التحسينات مؤخرًا، حتى في أحدث إصدار من Chrome Canary، ما نعتقد أنّه سيسهّل بشكل كبير تصحيح أخطاء الرسوم المتحركة.

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

تتبُّع Chrome

أخيرًا، باستخدام ميزة "تتبُّع Chrome"، وهي الأداة المفضّلة للتوغّل في التفاصيل، يمكنك تسجيل عملية تتبُّع "عرض محتوى الويب" من خلال واجهة مستخدم Perfetto الجديدة (أو about:tracing)، والتعمّق في مسار معالجة الرسومات في Chrome. قد تكون هذه مهمة شاقة، ولكن تم مؤخرًا إضافة بعض الميزات إلى Chromium لتسهيلها. يمكنك الاطّلاع على نظرة عامة على ما هو متاح في مستند رحلة الإطار.

من خلال أحداث التتبّع، يمكنك تحديد ما يلي بدقة:

• الصور المتحركة التي يتم عرضها (باستخدام الأحداث التي تحمل الاسم TrackerValidation)
• الحصول على المخطط الزمني الدقيق لإطارات الصور المتحركة (باستخدام الأحداث التي تحمل الاسم PipelineReporter)
• بالنسبة إلى التحديثات غير السلسة للرسوم المتحركة، حدِّد بالضبط ما الذي يمنع الرسوم المتحركة من العمل بشكل أسرع (باستخدام تقسيمات الأحداث ضمن أحداث PipelineReporter).
• بالنسبة إلى الرسوم المتحرّكة المستندة إلى الإدخال، يمكنك الاطّلاع على الوقت المستغرَق للحصول على تعديل مرئي (باستخدام الأحداث التي تحمل الاسم EventLatency).

الخطوات التالية

تهدف مبادرة مؤشرات أداء الويب إلى توفير مقاييس وإرشادات ل تقديم تجارب رائعة للمستخدمين على الويب. إنّ المقاييس المستندة إلى المختبر، مثل Total Blocking Time (TBT)، هي ضرورية لرصد وتحديد المشاكل المحتملة في التفاعل وحلّها. ونخطّط لمحاولة تصميم مقياس مماثل يستند إلى بيانات من المختبر لقياس سلاسة الرسوم المتحركة.

سنطلعك على آخر الأخبار بينما نواصل العمل على أفكار لتصميم مقياس كامل يستند إلى بيانات إطارات الرسوم المتحركة الفردية.

في المستقبل، نريد أيضًا تصميم واجهات برمجة تطبيقات تتيح قياس أداء fluidity of animation (سلاسة الرسوم المتحركة) للمستخدمين الفعليين في الميدان وكذلك في المختبر. يُرجى متابعتنا لمعرفة آخر الأخبار.

ملاحظات

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

يمكنك إرسال ملاحظاتك إلى مجموعة Google web-vitals-feedback مع تضمين "[Smoothness Metrics]" في سطر الموضوع. يسرّنا معرفة رأيك.