Vscode-vibrancy: مشكلة السحب ، انقل النافذة عن طريق شريط العنوان

شكرا لردود الفعل وآسف جدا. لا أعرف كيف أصلح هذا. أعتقد أن هذا خطأ في النوافذ.

لقد واجهت هذه المشكلة أيضا

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

في الواقع ، لم أر مثل هذه المشكلة في نظام التشغيل windows 10 1809.

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

لقد جربت هذا فقط على Windows 1903. هل جرب أي شخص هذا الامتداد على أحدث إصدارات Insider من Windows؟ ومن المثير للاهتمام أن هذه المشكلة لا يبدو أنها تؤثر على استخدام وحدة معالجة الرسومات أو وحدة المعالجة المركزية.

أنا أيضًا عام 1903 وأواجه هذه المشكلة

نفس المشكلة عام 1903

نفس المشكلة

+1

نفس المشكلة عام 1903

يبدو أن إصدار 1903 ليس لدي مشكلة في 1809

+1

في الإصدار # 14 v1.0.6. لا يزال تأخر الماوس موجودًا ، لقد جربت العديد من الطرق ، ولا يمكنني حل المشكلة في عام 1903.

المشكلة ليست في الإلكترون ، ولا توجد حاليًا طريقة مثالية لفتح تأثير الأكريليك بدون UWP في عام 1903.

لا يزال تأخر الماوس موجودًا في أحدث معاينة من الداخل لنظام التشغيل Windows 10.

شكرًا لأخذ الوقت الكافي للنظر في هذاEYHN. أتساءل عما إذا كانت هناك طريقة لخداع Windows في التفكير في أن VSCode / Electron هو تطبيق UWP.

لقد جئت للتو إلى هنا للإبلاغ عن هذه المشكلة. مسرور إلى حد ما لأنني لست الوحيد الذي لديه.

على جهاز الكمبيوتر الخاص بي في العمل ، مواصفات جيدة إلى حد ما ، Windows 1809 - يتحرك دون تأخير على الإطلاق.
على جهاز الكمبيوتر المنزلي ، مواصفات أفضل بكثير ، Windows 1903 ، laggy as hell.

لقد مرت أيام عديدة وما زالت هذه المشكلة قائمة.
لقد قمت بدفع الكود الأصلي للنوافذ على https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli .
ربما يمكنك مساعدتي إذا كنت تعرف جيدًا النوافذ

الأخبار: في النافذة رقم 10 1903 ، وجدت أن تقليل "معدل الماوس" إلى ما دون معدل الإطارات يمكن أن يحل هذه المشكلة بشكل فعال.

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

لا تقلق ، نفس المشكلة تظهر أيضًا في Microsoft Office ، الآلاف من مستخدمي Windows قلقون من ذلك ، فيما يلي بعض المناقشات:

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

توجد الآن بعض الطرق:

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

• تقليل معدل الاقتراع الماوس
  في العديد من لوحات تشغيل الماوس للألعاب ، يمكن ضبط معدل اقتراع الماوس.

  سأقدم أيضًا إصدارًا شفافًا فقط ، يزيل التعتيم والتوافق مع جميع أنظمة التشغيل والبيئات.

我 花 了 好 几天 研究 这个 问题 ， 现在 我 放弃 了。 看来 是 DWM 内部 的 问题 ， 鼠标 回报 率高 于 屏幕 刷新率 导致 渲染 请求 阻塞 在 队列 里 ， 看起来 就像 鼠标 延迟 一样。

不要 担心 ， 同样 的 问题 还 出现 在 Office 软件 中 ， 上千 Windows 用户 受到 其 困扰 ， 以下 是 一些 讨论 ：

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

现在 有 几种 备用 方法 ：

• 使用 Windows 10 1809 ， 然后 等待 微软 修复 问题
• 关闭 "拖动 时 显示 窗口 内容"
  在 任务 栏 搜索 性能 ， 选择 “调整 Windows 外观 和 性能”، 在 “视觉 效果” 选项 卡 关闭 “拖动 时 显示 窗口 内容”
• 降低 鼠标 回报 率一般 游戏 鼠标 驱动 面板 都 可以 调整 鼠标 回报 率

之后 我 还会 提供 一个 仅 透明 版本 ， 去掉 模糊 效果 并 兼容 所有 操作系统 和 桌面 环境。

EYHN أعتقد أنني وجدت حلاً.
في تطبيق إلكترون آخر ، يقدمون إعداد "نوع الخلفية" ، ونوعان "طمس" و "طليق" ، تستدعي وظيفة this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) ، ووجدت أن "Fluent" يعمل متأخرًا ولكن "Blur" يعمل جيدا. لا أعرف كيف يعمل this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) ، لكنني أعتقد أن هذا هو الحل قبل أن يصلحه MS في DWM.

بعد أن قمت بتثبيت Aero Glass ، قمت بتغيير رمز معالجة win10 لاستدعاء dwm (أي ، تطبيق win7) ولن تتجمد النافذة عند سحبها في win10 1909.

بعد أن قمت بتثبيت Aero Glass ، عندما قمت بتغيير رمز معالجة win10 لاستدعاء dwm (أي تطبيق win7) جزء من التشغيل على win10 1909 ، لن تتجمد النافذة.

ومع ذلك ، فإن Aero Glass لا يعمل في win10 2004

بعد أن قمت بتثبيت Aero Glass ، عندما قمت بتغيير رمز معالجة win10 لاستدعاء dwm (أي تطبيق win7) جزء من التشغيل على win10 1909 ، لن تتجمد النافذة.

ومع ذلك ، فإن Aero Glass لا يعمل في win10 2004

لن ينجح أخذ الملف من حزمة التصحيح الخاصة بالتطوير العام لـ win10 ثم طلب إعادة إنشاء الرموز؟

هناك طريقة أخرى وهي وضع النوافذ في وضع توفير الطاقة ، والذي عادةً ما يعطل جميع تأثيرات الشفافية ، ولكن لسبب ما يعمل على إصلاح التأخر 🤷‍♂️

يبدو أن إصدار Win 10 2004 KB4541738 يعمل على إصلاح هذه المشكلة.

هل يمكنك تقديم حل مفصل ، لا يزال هناك تأخير في السحب على windows1909

غريب ، لقد اعتدت على الجري بدون حزم بالسحب العادي دون تأخير ، لكن الآن هناك تأخير ...

يبدو أن إصدار Win 10 2004 KB4541738 يعمل على إصلاح هذه المشكلة.

وسيم

هل يمكنك تقديم حل مفصل ، لا يزال هناك تأخير في السحب على windows1909

هل يمكن لعام 1909 استخدام زجاج Aero مباشرةً؟ ملاحظة: يجب تعديل كود الامتداد

نظرًا لوجود خطأ في السحب ، فهل يمكن حله من خلال توفير صورة خلفية شفافة بتأثير زجاج بلوري بدلاً من ذلك؟

استخدام EasyWindowDrag لتحريك النافذة يمكن أن يخفف هذه المشكلة

بالنسبة لي ، أصبح سحب النافذة مستحيلًا مع تثبيت هذا الامتداد. النافذة تتحرك بحركة بطيئة. إنها ليست مشكلة موارد CPU / GPU.

هذا جعل رمز VS غير قابل للاستخدام. اضطررت إلى إلغاء تثبيت هذا الامتداد لاستخدام رمز VS مرة أخرى.

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

@ Toby56 لم أكن متأكدًا مما إذا كانت هي نفس المشكلة كما وصفها OP. يبدو مختلفًا عن GIF الذي قدمه.

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

إذن ، هل لا تزال هذه مشكلة في أحدث إصدارات Win10؟ لا ترغب في تثبيت هذا إذا كان سيؤدي بشكل أساسي إلى كسر VSCode بالنسبة لي ...

iPyGuy نعم بشكل أساسي ، لا تتوقع إصلاحه في أي وقت قريب. إنها ليست طريقة Windows الرسمية.

يبدو أن إصدار Win 10 2004 KB4541738 يعمل على إصلاح هذه المشكلة.

لم يتم دمج هذا التصحيح في 2004 الرسمية ولم يتم إصداره إلى القناة نصف السنوية.

تضمين التغريدة
هل تعتقد أنه يمكن "إصلاح" هذا من خلال تعطيل تأثير الأكريليك أثناء تحريك النافذة ، كما هو موضح هنا (@ Toby56): https://github.com/23phy/ewc/issues/22#issuecomment -599448590؟

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

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

لكنها تعمل في الغالب وستكون أفضل بكثير من العبث بالسجل أثناء التنقل. بالتأكيد لا أعتقد أن القيام بذلك أمر عملي.

هههههههههههههههه

ينكسر الأكريليك عند تمكينه من تأثير ضبابي آخر في وضع توفير البطارية لأن الأكريليك يتم تعطيله عادةً في هذا الوضع؟

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

لا توجد طريقة لمعرفة ما إذا كان في وضع توفير شحن البطارية أم لا على حد علمي ولن يكون توفير البطارية أمرًا شائعًا للغاية. لا أعلم.

بالنسبة لي ، يتم تمكينه تلقائيًا بمجرد وصول بطارية 20 ٪ ، لذلك لن أقول إنه غير شائع. لكن يمكنك اكتشافها!
إنه ممكن مع روابط العقدة لواجهة برمجة تطبيقات Windows Runtime API :

const { PowerManager } = require('@nodert-win10/windows.system.power')

let energySaverEnabled = PowerManager.energySaverStatus === 2

PowerManager.on('energySaverStatusChanged', () => {
  energySaverEnabled = PowerManager.energySaverStatus === 2
})

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

بالنسبة لهذه المشكلة المحددة ، لا أعرف كيف يتم هيكلة الكود في هذا المشروع ، فسيتعين علي أن أسأل EYHN إذا كانوا يريدون تنفيذ شيء كهذا. ربما سأقوم بنشر صورة GIF منه في العمل.

هههههههههههههههه
لقد أدركت للتو أن التبعيات الأصلية ربما لا تكون خيارًا في امتدادات VSCode ، لذلك بينما يجب أن يساعد هذا الحل كل من يريد إضافة تأثير الأكريليك إلى تطبيق Electron الخاص بهم (حتى يتمكنوا من تجميعه مقابل إصدار Electron / Node الخاص بهم) ، أنا لا أعرف ما إذا كان يساعد هنا: /

قد تحتاج على الأرجح إلى شحن ثنائي منفصل مسبق الإنشاء بدلاً من استخدام روابط Node ، حيث يقوم هذا المستودع بالفعل باستخدام blur-cli.exe 🤔

تضمين التغريدة
هذا صحيح! لم أفكر في ذلك. ليس لدي أي فكرة عن كيفية القيام بذلك ، ولكن من المحتمل أن يتم تضمينه في جزء C ++ الذي تم تجميعه في الملف الثنائي ؟؟؟ لا أعرف حقًا قيود امتدادات VSCode.

بالتأكيد مفيد لتطبيقي الخاص مع 😀!

صحيح ، من المحتمل أن يعمل هذا. لسوء الحظ ، لا أعرف حقًا أي شيء عن C ++ أيضًا (بخلاف القليل المطلوب لبرمجة Arduinos): /

على أي حال ، إذا تم تنفيذ ذلك ، فمن المؤكد أن يكون اختياريًا ، حيث يمكن للأشخاص الذين لديهم شاشات 144 هرتز على سبيل المثال أن يتمتعوا بالحيوية أثناء حركة النافذة إذا قاموا بتعيين معدل عينة الماوس الخاص بهم على شيء مثل 125 ، والذي يجب أن يكون سريعًا بدرجة كافية للاستخدام اليومي.

تضمين التغريدة
نعم ، لقد وجدتها أيضًا.
خلفية الأكريليك في النهاية لها خياران:

Blur ليس لديه مشكلة ، و Fluent لديه مشكلة تأخير أيضًا.

لذلك أعتقد أن هذا هو الجواب.

لست متأكدًا مما إذا كان ذلك مفيدًا ولكن النافذة الطرفية لها تأثير شفافية العمل. يسمونه "أكريليك".
المحطة الطرفية لا تعتمد على الإلكترون ... يتم تنفيذها في C ++.

يمكنك أيضًا تغيير التعتيم:

ربما يمكن أن يساعد النظر في تنفيذها:

https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalControl/TermControl.cpp#L376

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

Jinhaihan نعم ، صحيح ، يمكننا فقط جعلها ضبابية بهذا الشكل ، وليس لديها مشكلة! ربما يجب علينا. لكن imo لا يبدو جميلًا مثل تأثير الأكريليك "بطلاقة". أعتقد أنه تأثير قديم مستخدم في Windows 7 (Aero) ، أو شيء من هذا القبيل. نصف قطر التمويه ليس كثيرًا ، ولا يحتوي على نسيج "أكريليك" Windows 10 بطلاقة ، بالإضافة إلى الطبقات الأخرى التي تجعل طمس الاكريليك يبدو جميلًا.

إن وجود خيار مثل Terminus ممكن تمامًا ، وربما يكون حلًا يسعد الكثيرون به.

@ Toby56 قد يكون هذا سؤالاً غبيًا: هل من المستحيل السير على الطريقة "الرسمية"؟

Spenhouet ربما ، إذا كنت ترغب في إعادة كتابة رمز VS من الألف إلى الياء. خلاف ذلك ، ربما لا.

لا أعرف في الواقع الكثير عن كيفية تطبيق تأثير الأكريليك على نافذة الكروم باستخدام Node JS و C ++. لكن VS Code يُصنع وسيظل دائمًا في Electron ، ولا توجد طريقة مدعومة رسميًا للقيام بذلك. أنا مندهش جدًا من أن هذه الطريقة تعمل على الإطلاق. لذلك ما لم يجد بعض العبقري طريقة أخرى ، فإننا عالقون هكذا.

@ Toby56 حسنًا ، هذا منطقي.

أعتقد أن تأثير الأكريليك سيكون أكثر حضوراً في Windows في المستقبل. من المحتمل أن يتبنى رمز VS ذلك في هذا المستقبل البعيد.

تضمين التغريدة
نعم ، يعد تأثير الأكريليك حاليًا إحدى ميزات XAML ، وهو إطار عمل واجهة المستخدم الذي لا يمكن أن تستخدمه إلا تطبيقات Windows الحديثة (النوع الذي تراه عادةً في Microsoft Store). لهذا السبب لا توجد مشكلة في Windows Terminal وغيرها. يمكن أن تستخدم تطبيقات "المدرسة القديمة" معظم واجهات برمجة التطبيقات الحديثة ، ولكن لا تستخدم تلك التي تعتمد على العرض أو العروض وما إلى ذلك.
لا أعرف أيضًا كيف يعمل الاختراق في هذا الريبو ، لكنه بالتأكيد اختراق 😃

ومع ذلك ، مع WinUI 3 القادم (جزء من Project Reunion ، محاولة Microsoft لتوحيد واجهات برمجة التطبيقات القديمة والحديثة) ، سنحصل على ميزة تسمى "XAML Islands" ، والتي تسمح باستخدام واجهة المستخدم الحديثة في التطبيقات التقليدية. إذن ينبغي أن يكون من الممكن إضافة أكريليك بدون اختراقات ، ربما حتى كميزة مباشرة للإلكترون نفسه. 🙏🏻

jonaskuske رائع ، هذا رائع جدًا ، لم أكن أعرف أن Microsoft تخطط لشيء كهذا !!! بعض الأشياء مثل رموز العلبة غير ممكنة لتطبيقات UWP بدون حزم تطبيق Win32 مصاحب.

يسعدني الإبلاغ عن أن Windows 10 Insider Preview (إصدار 20161) قد أصلح المشكلة بالنسبة لي.

LegoLivesMatter من الرائع سماع ذلك! يجب أن أنتقل إلى القناة المطلعة السريعة للتحقق من ذلك.

@ Toby56 حظا سعيدا!

تضمين التغريدة _ _

أستطيع أن أؤكد أنه تم إصلاحه في الإصدار 20161!
حسنًا في الغالب ...

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

يا فتى ، هل تبدو جيدة مع:

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

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

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

لسبب ما ، يؤدي استخدام سمة مع Stardock WindowBlinds إلى حل هذه المشكلة أيضًا. يجب أن تفعل شيئًا ما مع تكوين مدير النوافذ ولكن لا توجد فكرة عما يحدث. هناك وميض سريع عند تكبير النافذة ولكنه جيد.

لقد قمت بتثبيت قناة مطور windows-insider ، والسحب على ما يرام. ومع ذلك ، لا يزال تغيير الحجم يطرح مشاكل. لقد لاحظت أيضًا أن تطبيق winforms 64 بت الخاص بي باستخدام هذه الطريقة به هذه المشكلة ، ولكن ليس الإصدار 32 بت. أيضًا ، لدي تطبيق اختبار WPF 32 بت و 64 بت أثناء استخدام SetWindowCompositionAttribute ، ويتم تغيير حجمه بشكل جيد. أيضا ، Avalonia يغير حجمها بشكل جيد.

استخدم EasyWindowDrag (نمط كيدي) .ahk يمكن أن يخفف من هذه المشكلة

https://www.autohotkey.com/
https://lexikos.github.io/v2/docs/scripts/~~

https://autohotkey.com/board/topic/22565-updated-easywindowdrag-kdeahk-with-added-control-support/

شكرًا لردك ، لكنني ذكرت أنه ليس لدي مشكلات في السحب (أي تحريك النافذة) على قناة المطورين الداخليين ، ولكن لدي مشكلات في تغيير الحجم في تطبيق 64 بت.

يبدو أنه تم إصلاح هذا في إصدار Windows الذي أستخدمه الآن.
اكتشفت هذا فجأة ، لذا لست متأكدًا مما إذا كان هذا الإصدار.

doublethinkio أنا على windows 10 بناء 19042.541 وما زلت أواجه المشكلة؟

20H2 build 19042.572 هنا ولا يزال يحدث ، لذلك أعتقد أن شيئًا ما doublethinkio قد جعله يعمل بشكل صحيح. بالنسبة لي ، سحب الأعمال وهو سلس ، إنه بطيء جدًا. هذا يختلف عن بعض الأشخاص حيث يكون بطيئًا وغير سلس.

ذكر Jinhaihan أن Blur يعمل معهم في Terminus و Fluent لديه نفس المشكلة في هذا التعليق . أعجبتني 5 دقائق من البحث ويبدو أن "Blur" خرائط للخيار 3 ، المسمى ACCENT_ENABLE_BLURBEHIND في خرائط هذا المشروع blur-cli و "Fluent" للخيار 4 ، المسمى ACCENT_ENABLE_ACRYLIC in blur-cli . هذا غير قابل للتكوين ، وبدلاً من ذلك يتم اختيار ACCENT_ENABLE_ACRYLIC (يُسمى بالفعل ACCENT_ENABLE_ACRYLICBLURBEHIND في واجهة برمجة التطبيقات).

سيكون جعل هذا التكوين قابلاً للتكوين أمرًا بسيطًا للغاية ، لكن ليس لدي مجموعة أدوات Visual C ++ تم إعدادها لتكون قادرًا على إنشاء blur-cli جديد.

كيفية حذف تأثير الزجاج المصنفر ، أقوم بإلغاء تثبيت المكون الإضافي وحذف التكوين.لا يزال عديم الفائدة

doublethinkio ، شكرًا لتقديم حل بديل. حاولت تنفيذ EasyWindowDrag.ahk باستخدام autohotkey.exe . لسوء الحظ ، تلقيت الخطأ أدناه. ليس لدي أي مشاكل في تنفيذ البرامج النصية الأخرى لـ AutoHotkey.

حتى لو استخدمت النص الأصلي الذي قمت بتنزيله مباشرة من:
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

استخدم EasyWindowDrag (نمط كيدي) .ahk يمكن أن يخفف من هذه المشكلة

https://www.autohotkey.com/
https://lexikos.github.io/v2/docs/scripts/

; Easy Window Dragging -- KDE style (based on the v1 script by Jonny) 
; https://www.autohotkey.com
; This script makes it much easier to move or resize a window: 1) Hold down
; the ALT key and LEFT-click anywhere inside a window to drag it to a new
; location; 2) Hold down ALT and RIGHT-click-drag anywhere inside a window
; to easily resize it; 3) Press ALT twice, but before releasing it the second

لست متأكدًا حقًا مما إذا كان هذا يساعد ولكن إليك مشروع يبدو أنه قد يساعد في حل المشكلة.
نافذة سيو-ري / إلكترون-أكريليك

لقد وجدت أن تعيين الخلفية الخلفية لـ Terminus ( eugeny / terminus 1.0.127) في Fluent ، سيؤدي إلى تعيين الخلفية على أنها غير شفافة عند سحب النافذة. بعد التوقف أو البقاء مؤقتًا ، تستعيد النافذة الخلفية بطلاقة. لن يظهر التأخر.

ربما يكون هذا حلًا جيدًا للمشروع.

يحتوي أحدث إصدار (v1.0.10) على حل لتأخر الماوس ، يرجى الاطلاع هنا للحصول على التفاصيل .

تحرير: لقد جربت للتو الإصلاح. إنه بالتأكيد أسرع ، حتى عند 60 هرتز! شكرا لك!!!