Vscode-vibrancy: समस्या खींचें, शीर्षक बार द्वारा विंडो को स्थानांतरित करें

प्रतिक्रिया के लिए धन्यवाद और बहुत खेद है। मुझे नहीं पता कि इसे कैसे ठीक किया जाए। मुझे लगता है कि यह विंडोज़ में एक बग है।

मैंने भी इस समस्या में भाग लिया है

ऐक्रेलिक प्रभाव इलेक्ट्रॉन विंडो पर एक ड्रैग विलंब होगा। यदि आप ब्लर बिहाइंड या पारदर्शी ग्रेडिएंट का उपयोग करते हैं, तो यह दिखाई नहीं देगा।

वास्तव में, मैंने विंडोज़ 10 1809 में ऐसी समस्या कभी नहीं देखी।

यह समस्या Windows 1903 में होती है और मुझे नहीं पता कि यह केवल इस संस्करण में दिखाई देती है या नहीं। (वास्तव में, विंडोज 1903 में कुछ इंटरफ़ेस त्रुटियाँ सामने आई हैं।)

मैंने इसे केवल Windows 1903 पर आज़माया है। क्या किसी ने इस एक्सटेंशन को Windows के नए इनसाइडर संस्करणों पर आज़माया है? दिलचस्प बात यह है कि यह समस्या GPU या CPU उपयोग को प्रभावित नहीं करती है।

मैं भी 1903 का हूं और इस समस्या का सामना कर रहा हूं

1903 को भी यही समस्या

एक ही समस्या है

+1

1903 को भी यही समस्या

1903 का अंक प्रतीत होता है क्योंकि मुझे 1809 पर कोई समस्या नहीं है

+1

#14 v1.0.6 में। माउस लैग अभी भी मौजूद है, मैंने कई तरीके आजमाए हैं, और मैं 1903 में समस्या का समाधान नहीं कर सकता।

समस्या इलेक्ट्रॉन में नहीं है, और वर्तमान में 1903 में UWP के बिना ऐक्रेलिक प्रभाव को खोलने का कोई सही तरीका नहीं है।

नवीनतम विंडोज 10 इनसाइडर प्रीव्यू में माउस लैग अभी भी मौजूद है।

इस पर गौर करने के लिए समय निकालने के लिए धन्यवाद @EYHN। मुझे आश्चर्य है कि विंडोज़ को मूर्ख बनाने का कोई तरीका है या नहीं, वीएससीओडी/इलेक्ट्रॉन एक यूडब्ल्यूपी ऐप है।

मैं अभी यहां इस समस्या की रिपोर्ट करने आया हूं। कुछ हद तक खुशी है कि मैं अकेला नहीं हूं।

काम पर मेरे पीसी पर, कुछ हद तक सभ्य चश्मा, विंडोज 1809 - बिना किसी अंतराल के चलता है।
मेरे होम पीसी पर, बहुत बेहतर चश्मा, विंडोज 1903, नरक के रूप में सुस्त।

कई दिन बीत चुके हैं और यह समस्या जस की तस बनी हुई है।
मैंने विंडोज़ के लिए मूल कोड https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli पर पुश किया है।
हो सकता है कि आप मेरी मदद कर सकें यदि आप विंडोज़ के बारे में अच्छी तरह से जानते हैं

समाचार: विंडो 10 1903 में, मैंने पाया कि फ्रेम दर के नीचे "माउस दर" को कम करने से इस समस्या को प्रभावी ढंग से हल किया जा सकता है।

मैंने इस समस्या पर शोध करने में कुछ दिन बिताए, और अब मैं हार मान लेता हूँ। ऐसा लगता है कि डीडब्लूएम के अंदर एक समस्या है, माउस मतदान दर स्क्रीन दर से अधिक है, जिससे प्रतिपादन अनुरोध कतार में अवरुद्ध हो जाता है, और यह माउस देरी की तरह दिखता है।

चिंता न करें, माइक्रोसॉफ्ट ऑफिस में भी यही समस्या दिखाई देती है, हजारों विंडोज उपयोगकर्ता इससे परेशान हैं, निम्नलिखित कुछ चर्चाएं हैं:

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 की प्रतीक्षा करें
• 'खींचते समय विंडो सामग्री दिखाएं' बंद करें
  टास्कबार पर खोज बॉक्स में, 'प्रदर्शन' टाइप करें, फिर परिणामों की सूची में 'विंडोज़ की उपस्थिति और प्रदर्शन को समायोजित करें' चुनें। 'विज़ुअल इफ़ेक्ट' टैब पर, 'खींचते समय विंडो सामग्री दिखाएँ' का चयन रद्द करें।

• माउस मतदान दर कम करें
  कई गेमिंग में माउस ड्राइवर पैनल माउस पोलिंग रेट को एडजस्ट कर सकते हैं।

  मैं एक पारदर्शी एकमात्र संस्करण भी प्रदान करूंगा, जो सभी ऑपरेटिंग सिस्टम और वातावरण के साथ धुंधलापन और संगतता को हटा देगा।

डीडब्लूएम内部的问题，鼠标回报率高于屏幕刷新率导致渲染请求阻塞在队列里，看起来就像鼠标延迟一样。

कार्यालय软件中，上千विंडोज़用户受到其困扰，以下是一些讨论：

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

मैं

• विंडोज 10 1809，然后等待微软修复问题
• "拖动时显示窗口内容"
  "调整 विंडोज़ ", "视觉效果" "拖动时显示窗口内容"
• मैं

मैं

@EYHN मुझे लगता है कि मुझे एक समाधान मिला।
एक अन्य इलेक्ट्रॉन ऐप टर्मिनस में, वे एक सेटिंग "बैकग्राउंड टाइप", और दो प्रकार "ब्लर" और "फ्लुएंट" प्रदान करते हैं, यह एक फंक्शन को कॉल करता है this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , और मैंने पाया कि "फ्लुएंट" लैग लेकिन "ब्लर" काम करता है। अच्छा काम करता है। मुझे नहीं पता कि this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) कैसे काम करता है, लेकिन मुझे लगता है कि यह एक समाधान है इससे पहले कि MS इसे DWM में ठीक करे।

एयरो ग्लास स्थापित करने के बाद, मैंने dwm (यानी, win7 कार्यान्वयन) को कॉल करने के लिए win10 प्रोसेसिंग के लिए कोड बदल दिया और win10 1909 में खींचे जाने पर विंडो फ्रीज नहीं होगी।

एयरो ग्लास स्थापित करने के बाद, जब मैंने win10 1909 पर चलने के dwm (यानी, win7 कार्यान्वयन) भाग को कॉल करने के लिए win10 प्रोसेसिंग के लिए कोड बदल दिया, तो विंडो फ्रीज नहीं होगी।

हालांकि एयरो ग्लास win10 2004 . में काम नहीं करता है

एयरो ग्लास स्थापित करने के बाद, जब मैंने win10 1909 पर चलने के dwm (यानी, win7 कार्यान्वयन) भाग को कॉल करने के लिए win10 प्रोसेसिंग के लिए कोड बदल दिया, तो विंडो फ्रीज नहीं होगी।

हालांकि एयरो ग्लास win10 2004 . में काम नहीं करता है

Win10 सामान्य विकास के डीबग पैकेज से फ़ाइल लेना और फिर प्रतीकों के पुनर्निर्माण का आदेश देना काम नहीं करेगा?

दूसरा तरीका विंडोज़ को पावर सेविंग मोड में डालना है, जो आमतौर पर सभी पारदर्शिता प्रभावों को अक्षम करता है, लेकिन किसी कारण से यह अंतराल को ठीक करता है ‍♂️

ऐसा लगता है कि विन 10 2004 संस्करण KB4541738 इस समस्या को ठीक करता है।

क्या आप एक विस्तृत समाधान प्रदान कर सकते हैं, windows1909 में अभी भी ड्रैग विलंब है

अजीब बात है, मैं बिना देर किए नॉर्मल ड्रैग के साथ अनपैक्ड दौड़ता था, लेकिन अब देरी हो रही है...

ऐसा लगता है कि विन 10 2004 संस्करण KB4541738 इस समस्या को ठीक करता है।

awsome

क्या आप एक विस्तृत समाधान प्रदान कर सकते हैं, windows1909 में अभी भी ड्रैग विलंब है

क्या 1909 में सीधे एयरो ग्लास का उपयोग किया जा सकता है? ps: एक्सटेंशन कोड को संशोधित करने की आवश्यकता है

चूंकि खींचने में एक बग है, क्या इसके बजाय फ्रॉस्टेड ग्लास प्रभाव के साथ एक पारदर्शी पृष्ठभूमि छवि प्रदान करके इसे हल किया जा सकता है?

विंडो को स्थानांतरित करने के लिए EasyWindowDrag का उपयोग करें इस समस्या को दूर कर सकते हैं

मेरे लिए इस एक्सटेंशन को स्थापित करने के साथ विंडो को खींचना असंभव हो गया। खिड़की धीमी गति से चल रही है। यह सीपीयू/जीपीयू संसाधन समस्या नहीं है।

इसने वीएस कोड को अनुपयोगी बना दिया। मुझे फिर से वीएस कोड का उपयोग करने के लिए इस एक्सटेंशन को अनइंस्टॉल करना पड़ा।

@Spenhouet हमें यह याद दिलाने के लिए धन्यवाद कि यह बग क्या है। यह एक विंडोज़ समस्या है जो इस तरह के असमर्थित तरीके से एक्रिलिक प्रभाव का उपयोग करने के परिणामस्वरूप आती ​​है, और वास्तव में कोई अच्छा समाधान नहीं है।

@ Toby56 मुझे यकीन नहीं था कि यह वही मुद्दा है जैसा ओपी ने वर्णित किया है। यह उसके द्वारा प्रदान किए गए GIF से भिन्न दिखता है।

@Spenhouet हाँ, जीआईएफ बहुत स्पष्ट नहीं है, लेकिन जैसा आपने वर्णन किया है वैसा ही है! यह एक माउस पोलिंग मुद्दा है, जहां जैसे ही आप घसीटना शुरू करते हैं, खिड़की जितनी धीमी होनी चाहिए, उससे धीमी हो जाती है, और जहां यह है और जहां होना चाहिए, उसके बीच भारी देरी जमा हो जाती है। दुर्भाग्य से, आप इसके बारे में कुछ नहीं कर सकते :(

तो क्या यह अभी भी नवीनतम Win10 रिलीज़ के रूप में एक मुद्दा है? अगर यह अनिवार्य रूप से मेरे लिए VSCode को तोड़ देगा तो इसे स्थापित नहीं करना चाहते हैं ...

@iPyGuy हाँ मूल रूप से, इसे जल्द ही किसी भी समय ठीक करने की उम्मीद न करें। यह एक आधिकारिक विंडोज़ विधि नहीं है।

ऐसा लगता है कि विन 10 2004 संस्करण KB4541738 इस समस्या को ठीक करता है।

इस पैच को आधिकारिक 2004 में विलय नहीं किया गया है और न ही अर्ध-वार्षिक चैनल के लिए जारी किया गया है।

@EYHN @Toby56
क्या आपको लगता है कि खिड़की को स्थानांतरित करते समय ऐक्रेलिक प्रभाव को अक्षम करके इसे "तय" किया जा सकता है, जैसा कि आपने (@ Toby56) यहां वर्णित किया है: https://github.com/23phy/ewc/issues/22#issuecomment -599448590 ?

वैकल्पिक रूप से, क्या आपको लगता है कि केवल VSCode सक्रिय/स्थानांतरित होने पर, फ़ोकस या मूव इवेंट पर संबंधित रजिस्ट्री प्रविष्टि को बदलकर, प्रदर्शन सेटिंग्स में "खींचते समय विंडो सामग्री दिखाएं" को अक्षम करना संभव होगा? सभी विंडो के लिए विंडो सामग्री नहीं देखना बहुत बुरा है, लेकिन अगर वह केवल VSCode को प्रभावित करता है तो मैं ट्रेडऑफ़ के साथ रह सकता हूं

@jonaskuske
ड्रैग पर ऐक्रेलिक प्रभाव को अक्षम करना शायद सबसे अच्छा आंतरिक फिक्स है। यह एक फिजूलखर्ची हो सकता है, लेकिन आप इसे बिना किसी धुंधलापन के सिर्फ पारदर्शिता में बदल सकते हैं। एक अन्य कारक जो इसे और अधिक जटिल बनाता है, वह यह है कि ऐक्रेलिक बैटरी सेवर मोड में एक और धुंधला प्रभाव से सक्षम होने पर टूट जाता है क्योंकि ऐक्रेलिक आमतौर पर उस मोड में अक्षम होता है? मुझे याद नहीं है। इस वजह से आपको हर बार ब्लर को रीसेट करना होगा जो एक छोटा सफेद फ्लैश बना सकता है। यह बताने का कोई तरीका नहीं है कि यह बैटरी सेवर मोड में है या नहीं जहां तक ​​​​मुझे पता है और बैटरी की बचत बहुत आम नहीं होगी। आईडीके

लेकिन यह अधिकांश भाग के लिए काम करता है और मक्खी पर रजिस्ट्री के साथ खिलवाड़ करने से बहुत बेहतर होगा। निश्चित रूप से मुझे नहीं लगता कि ऐसा करना व्यावहारिक है।

@ टोबी56

बैटरी सेवर मोड में एक और ब्लर इफेक्ट से इसे सक्षम करने पर ऐक्रेलिक टूट जाता है क्योंकि ऐक्रेलिक आमतौर पर उस मोड में अक्षम होता है?

हाँ, ऐक्रेलिक आमतौर पर एनर्जी सेवर मोड दोनों में अक्षम होता है और जबकि एक विंडो केंद्रित नहीं होती है। इसलिए आमतौर पर केवल एक विंडो होती है जिसमें ऐक्रेलिक प्रभाव सक्रिय होते हैं, जबकि पृष्ठभूमि वाले अपारदर्शी प्रदर्शित होते हैं।

यह बताने का कोई तरीका नहीं है कि यह बैटरी सेवर मोड में है या नहीं जहां तक ​​​​मुझे पता है और बैटरी की बचत बहुत आम नहीं होगी। आईडीके

मेरे लिए 20% बैटरी हिट करने के बाद यह स्वचालित रूप से सक्षम हो जाता है, इसलिए मैं यह नहीं कहूंगा कि यह असामान्य है। लेकिन आप इसका पता लगा सकते हैं!
यह मूल विंडोज रनटाइम एपीआई के लिए नोड बाइंडिंग के साथ है:

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

let energySaverEnabled = PowerManager.energySaverStatus === 2

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

@jonaskuske
यह बहुत अच्छा है कि आप देशी विंडोज़ कार्यों के लिए NodeJS बाइंडिंग का उपयोग करके बैटरी सेवर मोड का पता लगाने का एक तरीका जानते हैं! यह कुछ समस्याओं को हल करने का एक बहुत ही आसान तरीका लगता है। इस तरह हम कोड लिख सकते हैं जो आमतौर पर "ब्लर बैक" पर स्विच हो जाता है, और बैटरी सेवर मोड पर सादे पारदर्शिता के लिए, अनावश्यक सफेद फ्लैश को समाप्त कर देता है।

इस विशिष्ट समस्या के लिए, मुझे नहीं पता कि इस परियोजना में कोड कैसे संरचित है, अगर वे इस तरह कुछ लागू करना चाहते हैं तो @EYHN से पूछना होगा। हो सकता है कि मैं कार्रवाई में इसका एक जीआईएफ पोस्ट करूंगा।

@ टोबी56
मुझे अभी एहसास हुआ कि मूल निर्भरता शायद वीएससीओडी एक्सटेंशन में एक विकल्प नहीं है, इसलिए इस समाधान से उन सभी की मदद करनी चाहिए जो अपने स्वयं के इलेक्ट्रॉन ऐप में ऐक्रेलिक प्रभाव जोड़ना चाहते हैं (ताकि वे इसे अपने विशिष्ट इलेक्ट्रॉन/नोड संस्करण के खिलाफ संकलित कर सकें), I पता नहीं अगर यह यहाँ मदद करता है: /

संभवतः नोड बाइंडिंग का उपयोग करने के बजाय एक अलग पूर्व-निर्मित बाइनरी शिप करने की आवश्यकता होगी, क्योंकि यह रिपॉजिटरी पहले से ही blur-cli.exe के साथ कर रही है।

@jonaskuske
यह सच है! ऐसा नहीं सोचा। मुझे नहीं पता कि कैसे, लेकिन शायद इसे सी ++ भाग में बनाया जा सकता है जिसे बाइनरी में संकलित किया गया है ??? मैं वास्तव में VSCode एक्सटेंशन की सीमाओं को नहीं जानता।

मेरे अपने ऐप के लिए निश्चित रूप से उपयोगी है !

ठीक है, शायद यह काम करना चाहिए। दुर्भाग्य से मैं वास्तव में सी ++ के बारे में कुछ भी नहीं जानता (अरुडिनो को प्रोग्राम करने के लिए आवश्यक छोटे के अलावा): /

वैसे भी अगर इसे लागू किया जाता है तो यह निश्चित रूप से वैकल्पिक होना चाहिए, क्योंकि 144Hz मॉनिटर वाले लोगों में खिड़की की गति के दौरान जीवंतता हो सकती है यदि वे अपने माउस नमूना दर को 125 की तरह कुछ सेट करते हैं, जो अभी भी रोजमर्रा के उपयोग के लिए पर्याप्त तेज होना चाहिए।

@Quank123wip @EYHN
हाँ, मैंने भी पाया।
टर्मिनस में ऐक्रेलिक पृष्ठभूमि के दो विकल्प हैं:

ब्लर की कोई समस्या नहीं है, और फ्लुएंट में लैग की समस्या भी है।

तो मुझे लगता है कि यह जवाब है।

सुनिश्चित नहीं है कि यह किसी भी मदद की है, लेकिन विंडो टर्मिनल का कार्य पारदर्शिता प्रभाव है। वे इसे "एक्रिलिक" कहते हैं।
टर्मिनल इलेक्ट्रॉन पर नहीं बनता है... इसे C++ में कार्यान्वित किया जाता है।

आप अस्पष्टता भी बदल सकते हैं:

शायद उनके कार्यान्वयन को देखकर मदद मिल सकती है:

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

@Spenhouet हाँ, क्षमा करें, लेकिन यह वास्तव में हमारी बहुत मदद नहीं करता है। ओपन सोर्स विंडोज टर्मिनल के साथ-साथ कई अन्य ऐप इस प्रभाव (हमेशा ऐक्रेलिक कहा जाता है) का उपयोग करते हैं, लेकिन वे समर्पित विंडोज़ ऐप हैं और "आधिकारिक" तरीके से कर सकते हैं, जो आउट-ऑफ-द-बॉक्स काम करेगा। हालाँकि हम जो कर रहे हैं, वह कुछ ऐसा डाल रहा है जहाँ वास्तव में जाने का इरादा नहीं था, यही वजह है कि इसमें बग हैं जिन्हें ठीक नहीं किया जाएगा

@Jinhaihan हाँ, सच है, हम इसे इस तरह धुंधला कर सकते हैं, और इसमें कोई समस्या नहीं है! शायद हमें करना चाहिए। लेकिन इमो यह "धाराप्रवाह" ऐक्रेलिक प्रभाव के रूप में लगभग उतना अच्छा नहीं दिखता है। मुझे लगता है कि यह विंडोज 7 (एयरो), या ऐसा कुछ में इस्तेमाल किया जाने वाला एक पुराना प्रभाव है। धुंधला त्रिज्या उतना नहीं है, और इसमें धाराप्रवाह विंडोज 10 "एक्रिलिक" बनावट नहीं है, साथ ही अन्य परतें जो ऐक्रेलिक धुंध को अच्छा बनाने में जाती हैं।

टर्मिनस की तरह एक विकल्प होना पूरी तरह से संभव है, और शायद एक समाधान से कई लोग खुश होंगे।

@ Toby56 यह एक मूर्खतापूर्ण प्रश्न हो सकता है: क्या "आधिकारिक" तरीके से जाना असंभव है?

@Spenhouet हो सकता है, अगर आपको लगता है कि वीएस कोड को जमीन से फिर से लिखना है। वरना शायद नहीं।

मैं वास्तव में इस बारे में पूरी तरह से नहीं जानता कि Node JS और C++ का उपयोग करके क्रोमियम विंडो पर ऐक्रेलिक प्रभाव कैसे लागू किया जाता है। लेकिन वीएस कोड हमेशा इलेक्ट्रॉन में बनाया जाता है, और ऐसा करने का कोई आधिकारिक रूप से समर्थित तरीका नहीं है। मैं बहुत हैरान हूं कि यह तरीका बिल्कुल काम करता है। इसलिए जब तक कोई जीनियस दूसरा रास्ता नहीं खोज लेता, तब तक हम ऐसे ही फंस जाते हैं।

@ Toby56 ठीक है, समझ में आता है।

मुझे लगता है कि भविष्य में विंडोज़ में ऐक्रेलिक प्रभाव अधिक मौजूद होगा। वीएस कोड शायद इस दूर के भविष्य में अपनाएगा।

@स्पेनहौएट
हां, वर्तमान में ऐक्रेलिक प्रभाव एक्सएएमएल, यूआई फ्रेमवर्क की एक विशेषता है जिसका उपयोग केवल आधुनिक विंडोज ऐप (जिस प्रकार आप आमतौर पर माइक्रोसॉफ्ट स्टोर में देखते हैं) कर सकते हैं। इसलिए यह विंडोज टर्मिनल और अन्य के लिए कोई समस्या नहीं है। "ओल्ड-स्कूल" एप्लिकेशन अधिकांश आधुनिक एपीआई का उपयोग कर सकते हैं, लेकिन वे नहीं जो रेंडरिंग, व्यू आदि पर निर्भर हैं।
मैं या तो नहीं जानता कि इस रेपो में हैक वास्तव में कैसे काम करता है, लेकिन यह निश्चित रूप से एक हैक है

हालांकि, आगामी विनयूआई 3 ( प्रोजेक्ट रीयूनियन का हिस्सा, पुराने और आधुनिक एपीआई को एकीकृत करने के माइक्रोसॉफ्ट के प्रयास) के साथ हमें "एक्सएएमएल आइलैंड्स" नामक एक सुविधा मिलेगी, जो पारंपरिक अनुप्रयोगों में आधुनिक यूआई के उपयोग की अनुमति देती है। फिर बिना हैक के ऐक्रेलिक जोड़ना संभव होना चाहिए, शायद इलेक्ट्रॉन की प्रत्यक्ष विशेषता के रूप में भी। 🙏🏻

@jonaskuske वाह यह बहुत अच्छा है, नहीं पता था कि माइक्रोसॉफ्ट इस तरह कुछ योजना बना रहा था !!! एक साथी Win32 एप्लिकेशन की पैकेजिंग के बिना UWP ऐप्स के लिए ट्रे आइकन जैसी कुछ चीजें संभव नहीं हैं।

मुझे यह बताते हुए खुशी हो रही है कि विंडोज 10 इनसाइडर प्रीव्यू (बिल्ड 20161) ने मेरे लिए समस्या को ठीक कर दिया।

@LegoLivesMatter यह सुनकर बहुत अच्छा लगा! इसे सत्यापित करने के लिए मुझे फास्ट इनसाइडर चैनल पर जाना चाहिए।

@ Toby56 शुभकामनाएँ!

@jonaskuske @LegoLivesMatter @racoonx2p @EYHN

मैं पुष्टि कर सकता हूं कि यह बिल्ड 20161 में तय है!
वैसे ज्यादातर ...

मैं ज्यादातर इसलिए कहता हूं, जबकि यह अब बहुत अच्छा और पूरी तरह से प्रयोग करने योग्य है, यह थोड़ा सा विचित्र है। आकार बदलना अभी भी मेरे लिए यह मुद्दा है, जो कष्टप्रद है, लेकिन शायद किसी के लिए कोई मुद्दा नहीं है, जब तक कि आप खुद को बहुत अधिक आकार में नहीं पाते। लघु त्वरित आकार ठीक है।

लड़का, क्या यह अच्छा लग रहा है:

मेरे पास दोहरे मॉनिटर हैं, और यही समस्या भी है। साथ ही, यदि विंडो किसी भी मॉनिटर के किनारे के करीब है, तो उस किनारे का एक छोटा सा हिस्सा बिना धुंधलापन के पारभासी हो जाता है। अभी भी कुछ नहीं से बेहतर!

मैंने यह भी देखा है कि जब वीएस कोड विंडो को सेकेंडरी मॉनिटर पर बड़ा किया जाता है, तो ब्लर गायब हो जाता है लेकिन ऐक्रेलिक "फिल्टर" वहीं रहता है। मैं जो कह सकता हूं उससे यह खिड़की का परिणाम दूसरे मॉनीटर तक "पहुंचने" का परिणाम है। यह तब नहीं होता है जब वीएस कोड विंडो केंद्रित नहीं होती है या जब इसे प्राथमिक मॉनीटर पर अधिकतम किया जाता है।

@LegoLivesMatter हाँ मुझे भी यह समस्या थी, इसका उल्लेख करना भूल गया। इतना बेवकूफ, लेकिन खिड़कियां अक्सर अगले मॉनिटर में पहुंच जाती हैं, और यह स्पष्ट रूप से कारण है। हमारी उंगलियों को पार करें और शायद यह ठीक हो जाए। उम्मीद है कि दोनों प्रभाव तोड़ने और खिड़की पार करने!

किसी कारण से Stardock WindowBlinds के साथ एक थीम का उपयोग करने से वास्तव में यह समस्या भी हल हो जाती है। यह विंडो मैनेजर कंपोजिटिंग के साथ कुछ कर रहा होगा लेकिन पता नहीं क्या। खिड़की को अधिकतम करते समय एक त्वरित झिलमिलाहट होती है लेकिन अन्यथा यह अच्छा है।

मैंने विंडोज़-इनसाइडर देव-चैनल स्थापित किया है, और ड्रैगिंग ठीक है। हालाँकि, आकार बदलना अभी भी समस्याएँ हैं। मैंने यह भी देखा है कि इस विधि का उपयोग करके मेरे 64 बिट विनफॉर्म-ऐप में यह समस्या है, लेकिन 32 बिट संस्करण नहीं है। साथ ही, मेरे पास एक wpf परीक्षण ऐप है जो SetWindowCompositionAttribute का उपयोग करते समय 32 और 64 बिट है, और यह ठीक का आकार बदलता है। इसके अलावा, Avalonia ठीक का आकार बदलता है।

EasyWindowDrag(KDE शैली) का उपयोग करें। 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-बिट ऐप पर आकार बदलने में समस्याएं थीं।

ऐसा लगता है कि विंडोज़ के उस संस्करण पर तय किया गया है जिसका मैं अभी उपयोग कर रहा हूं।
मुझे यह सब अचानक पता चला, इसलिए मुझे यकीन नहीं है कि यह यह संस्करण है या नहीं।

@doublethinkio मैं विंडोज़ 10 पर 19042.541 का निर्माण कर रहा हूँ और अभी भी समस्या है?

20H2 यहाँ 19042.572 का निर्माण करता है और यह अभी भी होता है, इसलिए मुझे लगता है कि @doublethinkio विशेष रूप से कुछ ऐसा कर रहा है जिसने इसे सही ढंग से काम किया है। मेरे लिए, ड्रैगिंग काम करता है और चिकना है, यह बहुत धीमा है। यह कुछ लोगों से अलग है जहां यह धीमा और चिकना दोनों नहीं है।

@Jinhaihan ने उल्लेख किया कि ब्लर टर्मिनस में उनके लिए काम करता है और इस टिप्पणी में फ्लुएंट का एक ही मुद्दा है। मुझे 5 मिनट का शोध पसंद आया और ऐसा प्रतीत होता है कि इस परियोजना के blur-cli में ACCENT_ENABLE_BLURBEHIND नामक विकल्प 3 के लिए "धुंधला" मानचित्र और विकल्प 4 में "धाराप्रवाह" मानचित्र, जिसे ACCENT_ENABLE_ACRYLIC कहा जाता है blur-cli । यह विन्यास योग्य नहीं है, और इसके बजाय ACCENT_ENABLE_ACRYLIC (वास्तव में API में ACCENT_ENABLE_ACRYLICBLURBEHIND कहा जाता है) हमेशा चुना जाता है।

इसे कॉन्फ़िगर करने योग्य बनाना बहुत छोटा होगा, लेकिन मेरे पास एक नया ब्लर-क्ली बनाने में सक्षम होने के लिए एक विजुअल सी ++ टूलचेन स्थापित नहीं है।

पाले सेओढ़ लिया गिलास प्रभाव को कैसे हटाएं, मैं प्लगइन की स्थापना रद्द करता हूं और कॉन्फ़िगरेशन को हटाता हूं।अभी भी बेकार

@doublethinkio , वर्कअराउंड प्रदान करने के लिए धन्यवाद। मैंने EasyWindowDrag.ahk को autohotkey.exe के साथ निष्पादित करने का प्रयास किया। दुर्भाग्य से, मुझे नीचे त्रुटि मिलती है। मुझे अन्य AutoHotkey स्क्रिप्ट निष्पादित करने में कोई समस्या नहीं है।

भले ही मैं मूल स्क्रिप्ट का उपयोग करता हूं जिसे मैंने सीधे डाउनलोड किया है:
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

EasyWindowDrag(KDE शैली) का उपयोग करें। 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

वास्तव में यह सुनिश्चित नहीं है कि यह मदद करता है लेकिन यहां एक ऐसा प्रोजेक्ट है जो ऐसा लगता है कि यह समस्या से मदद कर सकता है।
एसईओ-आरआईआई/इलेक्ट्रॉन-ऐक्रेलिक-विंडो

मैंने पाया कि टर्मिनस ( यूजेनी/टर्मिनस 1.0.127) के बैकग्राउड को फ्लुएंट में सेट करना, यह विंडो को खींचते समय पृष्ठभूमि को गैर-पारदर्शी के रूप में सेट करेगा। रुकने या अस्थायी रूप से रहने के बाद, विंडो धाराप्रवाह पृष्ठभूमि को पुनर्स्थापित करती है। अंतराल नहीं दिखाई देगा।

शायद यह परियोजना के लिए एक अच्छा समाधान है।

नवीनतम संस्करण (v1.0.10) में माउस लैग का समाधान है, कृपया विवरण के लिए यहां देखें ।

संपादित करें: मैंने अभी ठीक करने की कोशिश की है। यह निश्चित रूप से तेज़ है, यहाँ तक कि 60 हर्ट्ज़ पर भी! शुक्रिया!!!