مستمعو Raw Input في الخلفية على Windows 10 وWindows 11

إجابة مختصرة: تقييد مستمع الخلفية إلى نحو 125 هرتز مؤكد بقياسنا الفعلي على Windows 11 24H2. مع تفعيل throttling النظامي بلغ متوسط الفاصل الزمني لأحداث WM_INPUT في الخلفية 7,97 مللي ثانية، أي نحو 125,5 هرتز؛ واحتفظ foreground بـ 1,04 مللي ثانية. وبعد تعطيل الآلية عاد background إلى 1,00 مللي ثانية. وفي بعض السلاسل الافتراضية لم يؤدِّ throttling إلى فقدان raw packets: فقد بقي 32 من 32 و256 من 256 حدثًا.

الحالة: آلية throttling وcoalescing لمستمعي الخلفية موثّقة من Microsoft. وقد قيست الترددات حول 125 هرتز بواسطة أداة اختبار عامة منفصلة باستخدام ماوس فعلي بتردد 1000 هرتز على Windows 11 24H2. كما لوحظ الفرع النظامي في Windows 11 25H2 ولم يُعثر عليه في Windows 10 22H2 المطابقة.

لماذا أضافت Microsoft هذا التقييد

تصف Microsoft السبب صراحةً: ماوس بمعدل تقارير مرتفع كان يرسل الإدخال ليس إلى اللعبة فقط، بل إلى عدة عمليات في الخلفية أيضًا. وكانت معالجة هذه الطلبات تستهلك وقتًا ملحوظًا من المعالج كان يمكن إنفاقه على العرض، ولوحظت تقطعات كبيرة على جهاز Surface Laptop Studio الاختباري مع ماوس بتردد 1000 هرتز. وكان الحل هو throttling وcoalescing وتقييد تردد الرسائل تحديدًا لمستمعي Raw Input في الخلفية.

وبحلول وقت صدور التغيير كانت الماوسات السريعة قد تجاوزت 1000 هرتز بكثير. فعلى سبيل المثال، أصدرت Razer ماوسًا سلكيًا بتردد 8000 هرتز في عام 2021 وتقنية لاسلكية بتردد 4000 هرتز في عام 2022. والجهاز بتردد 8000 هرتز قادر على إرسال ما يصل إلى ثمانية أضعاف عدد التقارير في الثانية مقارنة بجهاز 1000 هرتز. لذلك فإن انتشار الماوسات بتردد 4000–8000 هرتز كان يوسّع منطقيًا نطاق مشكلة تعدد مستمعي الخلفية.

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

الإعدادات ذات الصلة في BoosterX

ترتبط هذه المادة بإعداد «تقليل تردد أحداث Raw Input في الخلفية». وهو يقيّد مستمعي الخلفية تحديدًا، ولا ينبغي وصفه بأنه تقييد لإدخال foreground أو بأنه زيادة مضمونة في FPS.

الادعاءات التي جرى التحقق منها

تحققنا من خمسة ادعاءات:

1. يوجد في Windows 11 مسار معالجة منفصل لمستمعي Raw Input عالي التردد في الخلفية.
2. وهو غير موجود بالصورة نفسها في Windows 10 22H2 التي جرى فحصها.
3. في Windows 11 24H2 يبلغ التردد الفعلي لمستمع الخلفية فعلًا نحو 125 هرتز عند تدفق إدخال بنحو 1000 هرتز.
4. قد يقلل throttling من سلامة تدفق WM_INPUT اللعبة عبر الفقدان أو الدمج أو التقسيم للحزم.
5. تغيير نمط النافذة بحد ذاته ينشئ مسار Raw Input مختلفًا.

نطاق البحث

• Windows 10 22H2 build 19045.6456;
• Windows 11 24H2 مع ماوس فعلي بتردد 1000 هرتز;
• Windows 11 25H2;
• أجهزة افتراضية معزولة;
• مستهلكو foreground وbackground;
• التسجيل العادي لـ Raw Input وRIDEV_NOLEGACY وRIDEV_INPUTSINK;
• windowed وborderless وexclusive presentation مؤكد;
• سلاسل ضابطة من 32 حدثًا وسلسلة منفصلة من 256 حدثًا.

فحصت السلسلة الفعلية الفواصل الزمنية بين WM_INPUT، لكنها لم تتضمن مباراة حقيقية أو anti-cheat أو overlay. ولم تحاكِ السلسلة الافتراضية USB polling ولا GPU الفعلية ولا الشاشة ولا مسار click-to-photon.

المنهجية

في تجربة عامة منفصلة سجّل RawMouseThrottleBufferTester ماوسًا بـ RIDEV_INPUTSINK وقاس فواصل Stopwatch بين رسائل حركة WM_INPUT. وقورنت النافذة نفسها في foreground وbackground عند القيم النظامية الافتراضية، ثم بعد تعطيل throttling.

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

وبالإضافة إلى ذلك قُورنت مكونات نظام Windows 10 22H2 وWindows 11 25H2 مقارنةً ساكنة، للعثور على فرع معالجة منفصل لماوس الخلفية وللفصل بين مسار Raw Input ومسارات legacy cursor وpresentation.

ثم في بيئات افتراضية متطابقة أُرسلت سلسلة مضبوطة من mouse events إلى مستهلك foreground أو background. ولكل سيناريو سُجّلت أعداد raw packets المرسلة والمستلمة، والفقدان، والدمج، والتقسيم، وحالة foreground، وأحداث فرع legacy/cursor بشكل منفصل.

ولم يتغير إلا عامل واحد في كل مرة: طريقة تسجيل المستهلك، أو حالة foreground، أو نمط النافذة، أو ملف throttling النظامي. وبين السيناريوهات كانت حالة الاختبار تُعاد إلى baseline المسجّل.

النتائج

ماوس فعلي، Windows 11 24H2

الحالة	متوسط الفاصل لآخر 512 حدثًا	التردد المكافئ	Samples في اللقطة
Default, foreground	1,04 مللي ثانية	≈962 هرتز	2 221
Default, background	7,97 مللي ثانية	≈125,5 هرتز	3 556
Throttling معطّل، foreground	1,00 مللي ثانية	≈1000 هرتز	19 606
Throttling معطّل، background	1,00 مللي ثانية	≈1000 هرتز	12 009

وهذا يؤكد نحو 125 هرتز تحديدًا لمستهلك RIDEV_INPUTSINK في الخلفية في Windows 11 24H2 التي جرى فحصها. ولم يُقيَّد مسار foreground للبرنامج نفسه عند 125 هرتز.

السيناريوهات الافتراضية المضبوطة

السيناريو	Windows 10 22H2	Windows 11 25H2	النتيجة
التوصيل الأساسي لـ Raw Input	32 مرسلة، 32 مستلمة	32 مرسلة، 32 مستلمة	لم يُكتشف فقدان أو merge أو split
Background بدون RIDEV_INPUTSINK	0 من 32	0 من 32	لم يُطلب التوصيل في الخلفية
Background مع RIDEV_INPUTSINK	32 من 32	32 من 32	التوصيل في الخلفية يعمل على كلا النظامين
Windowed, borderless, exclusive	32 من 32 في كل نمط	32 من 32 في كل نمط	لم يغيّر Presentation mode سلامة الحزم
ملفات throttling تحت الضغط	لا ينطبق	256 من 256 في جميع الحالات	تغيّر فرع legacy/cursor، لا سلامة WM_INPUT

RIDEV_INPUTSINK هو مفتاح موثّق للتوصيل في الخلفية. وبدونه لا ينبغي لمستهلك background أن يتلقى التدفق نفسه الذي يتلقاه تطبيق foreground. والنتيجة الصفرية في هذا السطر ليست فقدانًا لبيانات Windows.

وفي سلسلة الضغط غيّرت حالات throttling النظامية عدد legacy events وحركة مؤشر النظام بشكل ملحوظ. ومع ذلك تلقى مستهلك Raw Input في جميع الحالات الحزم نفسها 256 من 256. لذلك لا يصح وصف الأثر المكتشف بأنه «Windows 11 تفقد Raw Input».

ما تم تأكيده

• أضافت Microsoft في Windows 11 throttling وcoalescing وتقييد تردد الرسائل لمستمعي raw mouse في الخلفية.
• على Windows 11 24H2 التي جرى فحصها كان مستهلك foreground الفعلي يتلقى الرسائل بفاصل نحو 1 مللي ثانية، ومستهلك background بفاصل 7,97 مللي ثانية، أي نحو 125,5 هرتز.
• بعد تعطيل throttling عاد فاصل مستهلك background إلى 1,00 مللي ثانية.
• في Windows 11 25H2 التي جرى فحصها يظهر فرع منفصل لهذه المعالجة؛ ولم يُكتشف في الزوج المطابق Windows 10 22H2.
• RIDEV_INPUTSINK يغيّر التوصيل في الخلفية WM_INPUT على كلا النظامين المفحوصين.
• في جميع السيناريوهات المذكورة بقيت سلامة raw packets بنسبة 1:1.
• ظهرت تغييرات throttling في فرع legacy/cursor المقيس، لا كفقدان raw packets.

ما لم يتم تأكيده

• أن كل مستمع خلفية في كل إصدار Windows 11 يُقيَّد دائمًا عند 125,0 هرتز بالضبط. فالنتيجة المؤكدة تخص Windows 11 24H2 الموصوفة وطريقة التسجيل.
• أن الآلية تقلل دائمًا FPS أو latency أو stutter على أي حاسوب.
• أن تعطيل throttling النظامي يحسّن التحكم بالماوس.
• أن DWM يدير سلامة WM_INPUT في جميع الألعاب وإصدارات Windows 11.
• أن تساوي سلامة الحزم يضمن تساوي click-to-photon latency الفعلية أو الإحساس الذاتي بالتوجيه.
• أن نتيجة الجهاز الافتراضي تنتقل إلى كل ماوس فعلي أو لعبة أو anti-cheat أو overlay.

القيود

لا تحتوي اللقطات الفعلية العامة على رقم build الدقيق لـ Windows 11 24H2، ولا طراز الماوس، ولا CSV بجميع الفواصل، ولا ترتيب آلي لتبديل الحالات. وتعكس القيمة المتوسطة آخر 512 حدثًا، وقد نُفّذت حركة الماوس يدويًا. لذلك تؤكد النتيجة بثقة العنقود المرصود عند نحو 8 مللي ثانية، لكنها لا تحدد ثابتًا دقيقًا لأي نظام.

يتيح الجهاز الافتراضي إعادة إنتاج المسار البرمجي، لكنه لا يحاكي USB polling ولا متحكم الماوس ولا GPU الفعلية ولا الشاشة ولا دورة اللعب الكاملة. والسلاسل المكونة من 32 و256 حدثًا كافية للتحقق من السلامة المرصودة لمسار معين، لكنها لا تكفي لتقدير حالات الفقدان النادرة ذات الاحتمال المنخفض.

قُورنت Windows 11 25H2 بإصدار واحد مطابق من Windows 10 22H2. ولا ينبغي نقل النتيجة تلقائيًا إلى إصدارات Windows 11 المبكرة أو Windows Server أو التحديثات المستقبلية.

أما كيفية إعادة إنتاج الجزء الديناميكي من الملاحظات — فراجع كيف تتحقق بنفسك.

يطوّر BoosterX كلاً من GameModeX وProcessX، وهذا البحث وأدواته، بما فيها RawMouseThrottleBufferTester العام، مملوكة لمطوّر BoosterX، لذا لديه مصلحة مباشرة في النتائج. وقد وُصفت المنهجية وحدود التطبيق أعلاه، ويمكن التحقق من الاستنتاجات عبر البيانات المفتوحة: الكود العام للأداة، ولقطات القياسات، والمصادر المذكورة. وقد نُشرت معًا النتيجة الصفرية بشأن فقدان WM_INPUT، وتأكيد نحو 125 هرتز، وغياب الضمان الشامل.

الاستنتاج العملي

على Windows 11 اترك throttling النظامي لمستمعي raw mouse في الخلفية على حالته الافتراضية. فقد أدخلته Microsoft لتقليل عمل تطبيقات الخلفية عند استخدام ماوس بمعدل تقارير مرتفع، مع الحفاظ على إدخال دقيق للعبة في foreground.

لحاسوب الألعاب يوصي BoosterX بتقييد مستمعي background المتوافقين إلى نحو 50 هرتز. ولم يُنشر بعد قياس خاص لهذا الفاصل في BoosterX؛ والرقم نفسه يتوافق مع قياسات مستقلة عامة: وفق فحوص PC-Tuning وNoverse فإن فاصلًا نحو 20 مللي ثانية يقابل تردد مستمع متوافق نحو 50–60 هرتز. وقد أُدرجت هذه المواد في المصادر كمقارنة إضافية، أما القيمة المقيسة في هذه المقالة فهي التقييد النظامي عند نحو 125 هرتز، لا التردد بعد الضبط اليدوي. وزيادة الفاصل تقلل عدد الأحداث الخلفية الموصَّلة وعدد مرات تشغيل المعالج عند حركة الماوس. أما نافذة foreground في المسار المفحوص فتحتفظ بإدخال كامل السرعة.

اتجاه التحسين المحلي مؤكد: تقليل تردد توصيل أحداث الخلفية يقلل عدد هذه التوصيلات وعدد مرات تشغيل المعالج. ولم يُقس حجم التغير الناتج في إجمالي CPU load أو FPS أو frametime لمجموعة برامج عشوائية. وقد تصبح استجابة التطبيق للماوس في الخلفية أقل سلاسة، لذا فإن المستمع الذي يحتاج فعلًا إلى تردد مرتفع في background هو سبب لإعادة Windows default. والوصف العملي وحالة Registry الدقيقة مذكوران في صفحة «تقليل تردد أحداث Raw Input في الخلفية».

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

وظيفة تقييد مستمعي الخلفية القديمة في GameModeX كانت مخصصة أساسًا لـ Windows 10 وليست بديلًا عن آلية Windows 11 النظامية. وللإعداد الجديد يُوصى بما يدعمه Windows 11 وProcessX.

استعادة الحالة

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

المصادر الأولية العامة

• RawMouseThrottleBufferTester — برنامج عام، وكود مصدري، وملاحظة ساكنة، وفحص WinDbg، وأربع لقطات لقياس فعلي على Windows 11 24H2.
• Default, foreground وdefault, background — 1,04 مللي ثانية مقابل 7,97 مللي ثانية.
• Throttling off, foreground وthrottling off, background — 1,00 مللي ثانية لكل منهما.
• Microsoft: Reduced game stutter with high report rate mice — throttling وcoalescing وcap لمستمعي raw mouse في الخلفية.
• Microsoft: KB5027303, OS build 22621.1928 — أول تحديث preview مستقر مع تحسين لماوسات معدل التقارير المرتفع.
• Microsoft: Windows 11 Insider Preview Build 23424 — وصف عام مبكر لتحسين ماوس معدل التقارير المرتفع أثناء اللعب.
• Razer: إصدار Viper 8KHz — الإعلان الرسمي عن ماوس 8000 هرتز بتاريخ 28 يناير 2021 ومقارنة حجم التقارير مع 1000 هرتز.
• Razer: تطوير 4000 و8000 هرتز — الجدول الزمني الرسمي لأجهزة معدل الاستطلاع المرتفع السلكية واللاسلكية.
• PC-Tuning: فحص فاصل مستمع الخلفية — منهجية عامة لملاحظة الفاصل ونطاق RawMouseThrottleDuration.
• Noverse: فحص مستقل لمستمعي خلفية اثنين — عند فاصل 20 مللي ثانية قيس مستمع متوافق عند نحو 60 هرتز، بينما احتفظ مستمع بتسجيل bypass بنحو 1000 هرتز.
• Microsoft: RAWINPUTDEVICE — الغرض من RIDEV_INPUTSINK وRIDEV_NOLEGACY.
• Microsoft: About Raw Input — نموذج تسجيل وتوصيل WM_INPUT.

تم التحقق من المصادر العامة والصياغات: 2026-08-24.

سجل التغييرات

• 2026-09-20: أُعيدت صياغة التوصية عند نحو 50 هرتز: قُوبل الرقم صراحةً بالقياسات المستقلة العامة، وأُشير إلى غياب قياس خاص منشور للفاصل؛ وأُكمل إخلاء المسؤولية بشأن تضارب المصالح بملكية البحث والأدوات، وأُضيف رابط للتحقق الذاتي في المنهجية.
• 2026-08-25: أُوصي بـ 50 هرتز لسيناريو الألعاب كتقليل مؤكد للمعالجة في الخلفية؛ وحُفظت بشكل منفصل الحدود المتعلقة بالأثر الرقمي على إجمالي CPU وFPS.
• 2026-08-24: أُضيف السياق الموثّق لـ CPU load، وحدود الاستنتاج بشأن ماوسات 4000–8000 هرتز، وسيناريو حذر للتقييد اليدوي لمستمعي الخلفية إلى نحو 50 هرتز.
• 2026-08-24: أُضيف قياس فعلي عام على Windows 11 24H2 يؤكد نحو 125 هرتز لمستمع الخلفية؛ وحُفظت الحدود بأنه ليس ثابتًا شاملًا لكل إصدار وطريقة تسجيل.
• 2026-08-24: نُشرت أول مقارنة بين Windows 10 22H2 وWindows 11 25H2.