كيف يعمل المحرّك

OLED Guard Pro ليس شاشة توقف، بل خط أنابيب فيديو يعمل في الوقت الفعلي ويقيم بكامله في الـ GPU، فيعالج كل إطار على كل شاشة متصلة وأنت تستخدم حاسوبك. هذه الصفحة هي الجولة التقنية في داخله.

خط الأنابيب رباعي المراحل

1. الالتقاط: Windows Graphics Capture / Desktop Duplication

يوفّر Windows واجهتي برمجة تمنحانك مقبض نسيج على الـ GPU لما يركّبه DWM لشاشة معيّنة: Windows Graphics Capture (WGC) وDXGI Desktop Duplication، ويدعم OLED Guard كلتيهما. يتيح إعداد طريقة الالتقاط الاختيار بين Auto وWGC وDesktop Duplication؛ فيختار Auto واجهة WGC على Windows 11، ويعتمد Desktop Duplication مساراً كلاسيكياً فيما عداه. ونفضّل WGC حيثما توفّرت لأنها تواصل تسليم الإطارات بمعدّلها الكامل داخل الألعاب العاملة بملء الشاشة، حيث قد تُحرم Desktop Duplication من الإطارات. وفي الحالتين تبقى الخصائص التي نعتمد عليها قائمة:

• يجري الالتقاط على الـ GPU، فلا يغادر مخزن الإطارات ذاكرة الفيديو أبداً.
• تعمل الواجهتان كلتاهما داخل الألعاب بوضع ملء الشاشة بلا حدود (وهو الوضع الذي يلعب به معظم اللاعبين فعلاً)، في حين لا تعمل الأساليب الأقدم مثل BitBlt أو PrintWindow.
• تُدعم HDR وتعدّد الشاشات والشاشات عالية معدّل التحديث من دون أي معالجة خاصة من جانبنا.

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

2. النمذجة: شيدر التعرّض لكل بكسل

يعالج شيدر بكسل كل إطار ملتقَط بالدقة الأصلية للشاشة، ويحسب لكل بكسل:

luminance     = dot(pixelRGB, vec3(0.2126, 0.7152, 0.0722));
delta         = luminance * frameTime;
exposure[p]   = exposure[p] + delta;

ويجري إلى جانب ذلك مساران متوازيان:

• غلاف الحركة. مرشّح زمني عالي التمرير زهيد الكلفة يجيب عن سؤال واحد: كم تغيّر هذا البكسل خلال آخر N إطاراً؟ يتلاشى التعرّض أسرع لدى البكسلات كثيرة الحركة، لأن المحتوى المتحرّك لا يركّز التقادم في موضع واحد.
• كاشف الثبات. مرشّح منخفض التمرير يعمل على غلاف الحركة: البكسلات التي ظلت قيمتها مستقرة عبر إطارات كثيرة تُعلَّم بوصفها «ثابتة» وتصبح مرشّحة للحماية.

يُخزَّن مدرّج التعرّض تخزيناً مزدوجاً في ذاكرة الـ GPU، ولا تجري أي قراءة عكسية إلى الـ CPU على المسار الساخن.

3. العرض: تحويل الخطر إلى مجال مستمر

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

• الإشغال (Occupancy) يجيب عن سؤال: «هل يوجد محتوى قابل للحماية بثبات هنا؟»، حتى لا تستدعي ومضة ساطعة عابرة أي تعتيم.
• الشدّة (Intensity) تجيب عن سؤال: «ما مقدار الحماية التي يريدها نموذج الخطر هنا؟».

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

في الوضع اليدوي تضبط الشدّة والتشكيل من صفحة Overlay. أما في Automatic Mode فيقرأ المتحكّم التصنيف الحي للإشارة (عمل، لعب، فيديو، خمول)، وغلاف الحركة لكل بكسل، وأثر الديناميكية، ثم يختار تهيئة يرى النموذج أنها تقلّل الخطر إلى أدنى حد ضمن ميزانية محدّدة للإدراك البصري. ويمكنك متابعة ذلك في قراءة Advanced > Live Classifier.

4. التركيب: DWM بألفا مسبق الضرب

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

• وضعي SDR وHDR،
• الألعاب بملء الشاشة بلا حدود،
• الشاشات ذات معدّل التحديث المتغيّر (G-Sync / FreeSync)،
• أنظمة تعدّد الشاشات،
• التهيئات ذات الـ DPI المختلط.

المزج الفعلي كله يتولاه DWM؛ ونحن لا نفعل سوى تزويده بإطار.

خط مستقل لكل شاشة، وبالتوازي

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

ما الذي يعمل على الـ CPU

يتولى الـ CPU ما يلي:

• ترجمة الشيدرات عند بدء التشغيل،
• الإعدادات المسبقة والتهيئة وواجهة React،
• مراقبة النافذة الأمامية لخدمة ملفات التطبيقات،
• أوامر DDC/CI عندما تغيّر السطوع من داخل التطبيق.

الـ CPU لا يرى محتوى شاشتك إطلاقاً؛ فالإطارات تبقى في ذاكرة الـ GPU طوال الوقت.

ميزانية الأداء

قياس تمثيلي عند 1440p / 144 Hz على بطاقة GPU من الفئة المتوسطة:

يعادل ذلك 7% من ميزانية قدرها 16.6 ms عند 60 Hz، لكنه يجري على جانب الـ GPU بدل أن يسد مسار الرسم في لعبتك، ولذلك لا يتجاوز الأثر الفعلي في الاختبارات المرجعية 1% في العادة. ترفع الدقات الأعلى ومعدّلات التحديث الأسرع وبطاقات الـ GPU الأضعف هذه الكلفة، لكن النسب بين المراحل تبقى كما هي.

ما الذي استُبعد عمداً

قرارات تصميمية أعدنا التحقق منها أكثر من مرة:

• لا نموذج خطر قائم على الخلايا. جرّبنا نموذجاً أولياً لطبقة حماية تستدل على بلاطات بحجم 32 × 32 ثم تخلّينا عنه؛ فالنمذجة لكل بكسل أصدق تمثيلاً للفيزياء، بينما أنتجت البلاطات الصلبة تشوّهات سُلّمية عند حدود المحتوى. أما مجال العرض في v5 فهو منخفض الدقة عن قصد، لكنه يُنعَّم ويُمزَج بتلاشٍ متصل باستمرار، فلا يُنتج تدرّجاً سُلّمياً كما كانت تفعل تلك البلاطات الصلبة، ويبقى نموذج الخطر الكامن يعمل لكل بكسل.
• لا استدلالات لاحتراق الشاشة على جانب الـ CPU. لا يحاول المحرّك أن يميّز أن «هذا الشريط الجانبي في Discord» أو «هذا شعار YouTube»؛ فالتعرّف على العناصر هش ويبلى سريعاً، أما التعرّض فهو المقدار الفيزيائي الصادق في كل حالة.
• لا قياس عن بُعد. المدرّجات المحسوبة لكل بكسل لا تغادر جهازك أبداً، وليست لدينا خوادم تستقبلها، وهذا اختيار مقصود.

إن أردت رؤية المحرّك وهو يعمل، فإن صفحة Advanced engine في تطبيق سطح المكتب تعرض المصنّف الحي، وآثار المتحكّم التلقائي لكل مقبض، وشريط الإشارات الحية بمعدّل 60 Hz.