उन लोगों के लिए एक समाधान जो समान रूप से बैटरी जीवन के बारे में जुनूनी हैं: कर्सर ब्लिंकिंग को अक्षम करने से सीपीयू का उपयोग 0. हो जाएगा।

  "editor.cursorBlinking": "solid"

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

TimelineRawData-20170321T114212.json.zip

• समयरेखा का स्क्रीनशॉट:

  

• एक ही फ्रेम में ज़ूम करते हुए, हम देखते हैं कि जब हम केवल 2 एफपीएस प्रस्तुत करते हैं, तो मुख्य धागा 60 एफपीएस (हर 16 एमएस) पर कुछ काम कर रहा है - तीर के साथ चिह्नित पतली रेखाएं:

  

• उन पतली रेखाओं में से सभी को ज़ूम करके, हम देखते हैं कि कुछ रेंडर 60 एफपीएस पर हो रहे हैं:

  

• जब मैं एक सीपीयू प्रोफ़ाइल लेता हूं, तो यह "प्रोग्राम ()) में खर्च होने वाले अधिकांश सीपीयू को दिखाता है, किसी विशिष्ट जेएस फ़ंक्शन को नहीं।

  

• जब मैं "editor.cursorBlinking": "solid" सेट करता हूं, तो समस्या ज्यादातर दूर हो जाती है: एक आवधिक "अपडेट लेयर ट्री" / "पेंट" / "कम्पोजिट लेयर्स" अभी भी हो रहा है, लेकिन हर 500ms में, हर 16ms में नहीं।

आशा है कि ये आपकी मदद करेगा!

@ जॉलिस हुड के तहत जो हो रहा है

समान (लगभग समान) क्रोमियम का मुद्दा https://bugs.chromium.org/p/chromium/issues/detail?id=500259 और क्रोमियम का ट्रैकिंग आइटम https://bugs.chromium.org/p/chromium-issues/detail ? id = 361,587

हमारे वर्तमान सीएसएस एनीमेशन

<strong i="11">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

.cursor-blink {
    animation: monaco-cursor-blink 1s step-start 0s infinite;
}

अपडेट करें

पॉल आयरिश (क्रोम आदमी) का उद्धरण https://news.ycombinator.com/item?id=13941293

वेब स्टैक पर बनाए गए शक्तिशाली * टेक्स्ट एडिटर OS टेक्स्ट कैरेट पर भरोसा नहीं कर सकते हैं और उन्हें स्वयं प्रदान करना होगा।
इस मामले में, VSCode संभवतः कर्सर को ब्लिंक करने के लिए सबसे उचित दृष्टिकोण का उपयोग कर रहा है: सीएसएस कीफ़्रेम एनीमेशन के साथ step टाइमिंग-फ़ंक्शन। यह ब्राउज़र को केवल 500ms की अपारदर्शिता को बदलने के लिए कहता है। इस बीच, क्रोम ने अभी तक इसे पूरी तरह से अनुकूलित नहीं किया है, इसलिए http://crbug.com/361587।
इसलिए वर्तमान में, Chrome हर 16ms में पूर्ण रेंडरिंग जीवनचक्र (शैली, पेंट, परतें) कर रहा है, जब उसे केवल 500ms के अंतराल पर ही काम करना चाहिए। मुझे विश्वास है कि क्रोम की शैली के घटकों पर काम करने वाले इंजीनियर इसे सुलझा सकते हैं, लेकिन यह थोड़ा काम लेगा। मुझे लगता है कि इस विषय पर जोड़ी गई दृश्यता निश्चित रूप से फिक्स की प्राथमिकता को बढ़ाएगी। :)

• सरल पाठ संपादकों, और बुनियादी [सामग्री] पर बनाया जा सकता है, लेकिन इस सुविधा के लिए शायद ही कभी सबसे अधिक पैमाने चाहते हैं।

क्या क्रोमियम टैब के पृष्ठभूमि CPU उपयोग के बारे में यह परिवर्तन संपादक को प्रभावित करेगा?

उम्मीद नहीं है (देखें https://github.com/electron/electron/issues/7553)। हम करते सेट backgroundThrottling करने के लिए false के बाद थोड़ी देर के पहले से ही।

अच्छे विश्लेषण के लिए @joliss @rebornix धन्यवाद।

ऐसा लगता है कि हमें OSX पर setInterval का उपयोग करके वापस जाना चाहिए।

पीएस यहाँ प्रारंभिक कर्सर निमिष तर्क है :)

@rebornix यहाँ एक ऐसा ही मुद्दा है जिसे हमने कुछ समय पहले चलाया था - https://bugs.chromium.org/p/chromium/issues/detail?id=658894। हमारे मामले में वर्कअराउंड डोम से एनिमेटिंग तत्व को हटाने के लिए किया गया था जब इसका उपयोग नहीं किया गया था, बल्कि इसे केवल हल करने के बजाय।

वर्तमान कार्यान्वयन के लिए लिंक -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

उसी के लिए एक सीएसएस शैली भी है, यह सुनिश्चित नहीं है कि यह यहाँ उपयोग किया जाता है -

<strong i="6">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.css

कर्सर एनीमेशन के लिए https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback का उपयोग क्यों नहीं किया?

PageVisibility API का उपयोग करें, जो आपको यह बताता है कि एनीमेशन को अक्षम करने के लिए पेज कब छिपा हुआ है।

function handleVisibilityChange() {
  if (document.hidden) {
    // disable cursor animation with class name
  } 
  else  {
    // add back cursor animation
  }
}
document.addEventListener("visibilitychange", handleVisibilityChange, false);

सीपीयू के बजाय जीपीयू का उपयोग करके सीएसएस एनीमेशन को प्रस्तुत करने के लिए यहां सुझाव:

.cursor-blink {
    will-change: opacity;
}

वर्तमान कार्यान्वयन में, यदि संपादक फोकस खो देता है, तो हम एनीमेशन को हटा देंगे ताकि जीवन आसान हो। हालाँकि यदि संपादक का ध्यान केंद्रित है, तो इसका मतलब है कि संपादक दिखाई दे रहा है (छिपी नहीं है या पृष्ठभूमि में) और सक्रिय है, उपयोगकर्ता इस पर काम कर रहे हैं (पढ़ना एक अच्छा मामला है) लेकिन किसी भी दृश्य / सामग्री परिवर्तन को ट्रिगर न करें। इस मामले में हमें अभी भी ब्लिंकिंग कर्सर को प्रदर्शित करने की आवश्यकता है, भले ही यह निष्क्रिय की तरह हो, यही एक ब्लिंकिंग कर्सर है।

प्रारंभ में यह सुविधा जावास्क्रिप्ट में लागू होती है और लगभग एक साल पहले, हमने CSS एनीमेशन पर स्विच किया। @Alexandrudima उल्लेखित की तरह, हम OSX पर JS को वापस ले जाना चाह सकते हैं।

@camwest कि एपी आकर्षक है, एकमात्र पकड़ संगतता है (दुख की बात है सफारी)।

@mehas will-change होनहार है। मैंने इसे आज़माया, लेकिन क्रोमियम इस मामले में अनुकूलन नहीं करता है। यदि आप Dev Tools में पेंट फ्लैशिंग विकल्प को चालू करते हैं, तो आप देख सकते हैं कि इस ब्लिंकिंग कर्सर को बिल्कुल भी रिपीट नहीं किया जा रहा है।

@jlukic @bcherny आपके सुझाव के लिए धन्यवाद। हम जिस चीज़ को ऑप्टिमाइज़ करना चाहते हैं, वह तब होता है जब कर्सर दृश्यमान, सक्रिय और ब्लिंकिंग होता है, इसलिए हमारे पास दृश्यता जांचने के बावजूद भी यह समस्या होती है। लेकिन आप सही हैं, हमें दृश्यता की जांच करनी चाहिए। अभी अगर आप विंडो को ब्लिंकिंग कर्सर को अदृश्य बनाने के लिए स्क्रॉल करते हैं, तो हमारे पास कोई अनुकूलन नहीं है।

निष्पक्ष होना, मोनाको वास्तव में, वास्तव में, वास्तव में जटिल है। :)

@rebornix- परिवर्तन ने मेरी परियोजना के लिए काम किया, सीपीयू का उपयोग पूरी तरह से गायब हो गया। हालाँकि, मेरी keyframes अस्पष्टता नहीं बदलते हैं .. इसके बजाय वे तत्व का रंग 'विरासत' से 'पारदर्शी' में बदलते हैं।

मैं सिर्फ एक lurker हूँ, और खेद है कि अगर यह शपथ ग्रहण माना जाता है, लेकिन एक दो फ्रेम एनिमेटेड gif चाल नहीं होगा? मुझे पूरी तरह से यकीन नहीं है कि इस निर्णायक परीक्षण को कैसे किया जाए, लेकिन मैं सोच सकता था कि क्रोम में ट्रांसगोमोर्फेड होने से बहुत पहले ही केएचटीएमएल ने उसके लिए पहले से ही अनुकूलित रास्ते बना लिए थे।

@eteeselink देखना दिलचस्प होगा, लेकिन कर्सर का रंग बदलने की जरूरत है और ज़ूम इत्यादि तुच्छ नहीं हो सकता है, इस बीच js पर वापस जाना आसान हो सकता है।

@matthiasg अहिसे, ज़ूम के बारे में भूल गए।

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

अगर कोई जीआईएफ कैरेट को जूम न करने के तरीके के साथ आ सकता है, तो मैं एक ऐसे कोड का योगदान करने का वादा करता हूं जो एक रंग लेता है और एक ब्लिंकिंग-केयर एनिमेटेड जीआईएफ डेटा यूआरएल बनाता है।

@eteeselink आपको बिलकुल चाहिए कि वेनिला JS में वैसे भी, शायद PHP और कुछ अन्य स्वादों के रूप में भी। मैं कल्पना कर सकता हूं कि इसे पूरे वेब पर कई टन उपयोग मिलेगा, और फिर आप सुपर-प्रसिद्ध होंगे यदि आपने एक लाइसेंस का उपयोग किया है जिसे मूल लेखक को स्वीकार करने की आवश्यकता है।

@eteeselink अगर हम ऑफ-द-वॉल सॉल्यूशन सुझाने जा रहे हैं, तो हम कैरेट को <blink></blink> बजाय क्यों नहीं लपेटते? :आँख मारना:

कृपया मुद्दों और पीआरओं पर बेकार टिप्पणी करने में रेडिट ब्रिगेड में शामिल होने से बचना चाहिए जहां लोग वास्तविक सुधार करने की कोशिश कर रहे हैं।

यदि संपादक का ध्यान केंद्रित है, तो इसका मतलब है कि संपादक दिखाई दे रहा है

यह एक गलत धारणा है। यह ध्यान केंद्रित किए बिना एक खिड़की को दूसरे पर उठाने के लिए तुच्छ है। दो तरीके मुझे पता हैं:

• "हमेशा शीर्ष पर आकर्षित" WM संकेत
• जब वर्चुअल डेस्कटॉप के बीच एक विंडो ले जाया जाता है (चूंकि स्टैकिंग ऑर्डर वैश्विक है, अगर पिछले डेस्कटॉप पर एक विंडो सबसे आगे थी, तो यह नए पर नहीं हो सकता है)।

दोनों अपने आप में बहुत सामान्य हैं, हालांकि वे हमेशा समस्या का कारण नहीं बनते हैं।

@ o11c धन्यवाद, लिखते समय मेरी धारणा बहुत जंगली थी। हां फोकस जरूरी नहीं है, दृश्यमान होना, विंडो को स्क्रॉल करना एक मामला है (मैंने उसी पैराग्राफ में इसका उल्लेख किया है :()। मुझे नहीं पता कि फोकस + दृश्य सबसे सामान्य मामला है लेकिन उन सभी को कम किया जाना चाहिए।

मुझे लगता है कि setTimeout या setInterval शायद इस उपयोग के मामले में requestIdleCallback से बेहतर है। requestIdleCallback का समय पूर्वानुमेय नहीं है, और जेएस में आप जो काम कर रहे हैं, वह सस्ता है, मुझे लगता है कि आप समय-सीमा के अनैतिक समय-निर्धारण से बेहतर होंगे।

पूर्व। https://gist.github.com/esprehn/afec30fbc655bba6bb8f3f67c28beef4

यह भी ध्यान दें कि यह कैरेट एनीमेशन एक सहज पल्स इफेक्ट कर रहा है, लेकिन ब्राउज़र में सिस्टम कर्सर (उदा। <input> या <textarea> ) केवल बाइनरी चालू / बंद कर रहा है । मैक और लिनक्स पर मूल नियंत्रण इसी तरह एक ब्लिंक करते हैं। यह कम सुंदर है, लेकिन काफी कम बिजली का उपयोग करेगा।

धन्यवाद @esprehn , कि वास्तव में मैंने फ्लैट ब्लिंकिंग के लिए अभी क्या किया है। और जैसा आपने उल्लेख किया है, यह एनीमेशन के रूप में बहुत सुंदर नहीं है, यहां तक ​​कि चिकनी कहने के लिए भी नहीं है / निमिष का विस्तार करें जो ease-in-out ।

प्रतीक्षा करें @eteeselink , क्या आप 1px gif का उपयोग नहीं करना चाहेंगे और इसे किसी भी तरह से बदल सकते हैं? ब्लर की समस्या नहीं होनी चाहिए।

उदाहरण: https://jsfiddle.net/mrkev/stxq613s/1/

जल्द ही उस एनिमेटेड ब्लिंकिंग-केयर्ट जनरेटर को देखने की उम्मीद है;)

@mrkev your 1px gif as data uri: data:image/gif;base64,R0lGODlhAQABAPAAAAAAAP///yH/C05FVFNDQVBFMi4wAwEAAAAh+QQFMgABACwAAAAAAQABAAACAkwBACH5BAUyAAEALAAAAAABAAEAAAICRAEAOw==

@rmacfadyen मीठा! चूंकि gifs सिद्धांत रूप में 3 बाइट्स वाले रंग तालिका का उपयोग करते हैं, जो कि "ऑन" फ्रेम पर पिक्सेल ब्लैक रंग को खोजने में बहुत कठिन नहीं होना चाहिए (वे फ्रेम में संग्रहीत नहीं होते हैं, इसलिए शायद हेडर से बहुत गहरे जाने की आवश्यकता नहीं है )। अगर मुझे कल कुछ खाली समय मिल जाए तो मैं इसमें और भी गहराई से डुबकी लगा सकता हूं

वेल्ड, जिसे वैसे भी नींद की ज़रूरत है, ने इसे थोड़ा आगे बढ़ाने का फैसला किया। चूंकि जीआईएफ एक वैश्विक रंग तालिका का उपयोग करते हैं जो हमेशा 14 वीं बाइट पर शुरू होता है, यह पता लगाना मुश्किल नहीं था कि रंग कैसे बदलना है। इसने पलक झपकते ही बना दिया gif red

अब वास्तव में कष्टप्रद यह है कि बेस 64 में प्रत्येक अंक केवल 6 बिट्स को एन्कोड करता है ताकि चीजें ठीक से संरेखित न हों। यह अंक 22 के सबसे महत्वपूर्ण अंकों में से सबसे कम 18 बिट्स है और उस gif में काले रंग को सांकेतिक शब्दों में बदलना है। तो अनिवार्य रूप से पात्रों का कुछ क्रमचय [A-P] [A-/] [A-/] [A-/] [P,f,v,/] 18-22 की स्थिति में हर रंग में उस पिक्सेल को आकर्षित करेगा।

यहाँ कुछ यादृच्छिक रंग पर उस GIF का एक उदाहरण है। मैंने अनिवार्य रूप से बस जो कुछ भी बदल दिया था वह 18-22 G8ABf (जो कि मैं उपरोक्त मानदंडों को पूरा करता हूं)।

https://jsfiddle.net/mrkev/stxq613s/7/

फ़ंक्शन को बनाने के लिए बहुत बुरा नहीं होना चाहिए जो RGB लेता है और इस gif को उस रंग में लौटाता है: (

मेरे पास 7 घंटे में कक्षा है, मैं सचमुच खुद को आरएन खेल रहा हूं।

लेकिन जो भी हो, मैंने महसूस किया कि किसी ने शायद पहले से ही एक हेक्स-टू-बेस 64 फ़ंक्शन लिखा था और इसे खोजने के लिए एक त्वरित स्टैकओवरफ़्लो खोज पर्याप्त थी। तो यहाँ समारोह है;

// takes color as string 'RRGGBB'
var generate_cursor_image = color => {
  var gif = '47494638396101000100F00000' + color + '00000021FF0B4E45545343415045322E30030100000021F90405320001002C00000000010001000002024C010021F90405320001002C00000000010001000002024401003B'
  return 'data:image/gif;base64,' + btoa(gif.match(/\w{2}/g).map(a => String.fromCharCode(parseInt(a, 16))).join(""))
}

सभी को शुभरात्रि!

अरे नहीं, @mrkev ने मुझे हराया। वैसे भी, यहाँ एक ही बात का मेरा कार्यान्वयन है:
https://jsfiddle.net/a6g4ob7h/

यह थोड़ा तेज़ हो सकता है क्योंकि कोई मैचिंग और मैपिंग नहीं हो रहा है, बस एक btoa है। लेकिन मुझे संदेह है कि गति के मामले, और परिणाम को कैश करना बेहतर है।

मैं वास्तव में आश्चर्यचकित हूं कि क्या यह चीजों को गति देता है। मेरे पास परीक्षण के लिए एक अच्छा सेटअप नहीं है, लेकिन कौन जानता है, शायद एनिमेटेड gifs 60fps पर भी रेंडर किए जाते हैं।

यदि आप ज़ूम करना चाहते हैं और आयताकार आकार का कर्सर नहीं है, तो आप एनिमेटेड एसवीजी के साथ भी जा सकते हैं। ( <animate> तत्व पहले से ही SVG 1.0 युक्ति का हिस्सा था।)

@eteeselink Max लगभग 50fps, http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser पर होना चाहिए

मेरे लिए यह सबसे अधिक समय तक रहता है (सीपीयू उपयोग पहला कॉलम है - ओएसएक्स 10.12.3 - मैकबुक प्रो रेटिना, 15-इंच, 2013 के अंत में)

मेरे पास कर्सर के संबंध में डिफ़ॉल्ट सेटिंग्स हैं।

जैसा कि किसी ने भी लिनक्स का उल्लेख नहीं किया है, मेरे पास वेनलैंड (आइवी ब्रिज ग्राफिक्स) के साथ GNOME शेल पर लगभग 5-7% है।

हमने अभी PR # 23121 को मर्ज किया है जो blink कर्सर ब्लिंकिंग स्टाइल के लिए setInterval जाकर इसे कम कर देता है। मैक मिनी पर मैं अपने निपटान में सीपीयू उपयोग 5.9% से 0.9% तक गिरता है

क्या आपने कभी देशी जाने और OS को कर्सर प्रदान करने, मुफ्त में उपलब्ध माना है?

बोली @rebornix से @justjoeyuk देखें के रूप में यह क्यों नहीं किया जा सकता है, इसके बाद के संस्करण

@justjoeyuk यदि आप इसके बजाय पूरी तरह से देशी, गैर वेब स्टैक आधारित अनुप्रयोग का सुझाव दे रहे हैं: जब आप एक भारी थीम्ड, पूरी तरह से DPI स्वतंत्र, क्रॉस-प्लेटफ़ॉर्म अनुप्रयोग जैसे VSCode, की संभावनाएँ पार करते हैं, तो संभावना है कि एक गैर-देशी कर्सर विकल्प होगा भले ही जरूरत हो।

ताज़ा खबर! Microsoft MacOS 10 पर बहुत अधिक प्रमुख होने के साथ Microsoft को बहुत ही धीमा सॉफ्टवेयर कोडित करता है।

किसने कभी अनुमान लगाया होगा, है ना?

@LandonPowell आप किसी मुद्दे के बारे में वास्तविक चर्चा को प्रदूषित कर रहे हैं; यहाँ reddit / hackernews ब्रिगेडिंग हास्यास्पद है।

टर्मिनल कर्सर के बारे में क्या? क्या यह सीपीयू चक्र में स्पाइक्स के कारण होता है?

@mehas

सीपीयू के बजाय जीपीयू का उपयोग करके सीएसएस एनीमेशन को प्रस्तुत करने के लिए यहां सुझाव:

यह सिर्फ CPU से GPU पर लोड को ले जाकर समस्या को छुपाता है। यह वास्तव में इसे ठीक नहीं करता है।

@ Daniel15

यह सिर्फ CPU से GPU पर लोड को ले जाकर समस्या को छुपाता है। यह वास्तव में इसे ठीक नहीं करता है।

CPU पर लोड की समस्या है, एनीमेशन के अनुकूलन GPU उपयोग करने के लिए इस समस्या को हल करता है।

(यह उस विशिष्ट फिक्स के सवाल से अलग है, जिसका मैंने सबसे अच्छा सुझाव दिया था)

वास्तव में यकीन नहीं है कि इसे कैसे पुन: पेश किया जाए। मैं विम अनुकरण प्लगइन का उपयोग कर रहा हूँ। वास्तव में यकीन नहीं है कि क्या यह संबंधित है।

मैं जानना चाहूंगा कि यह कैसे होता है।

GPU का उपयोग करने के लिए एनीमेशन का अनुकूलन इस समस्या को ठीक करता है।

हालांकि यह अनावश्यक GPU लोड में परिणाम देगा। यह एक समान मुद्दा है, सिवाय इसके कि भार ग्राफिक्स कार्ड के प्रोसेसर पर है। यह वास्तव में एक तय नहीं है 😛

जीसस का जन्म अफ्रीका में हुआ था।

आपका स्वागत है।

कर्सर के लिए gif का उपयोग क्यों नहीं किया जाता है?

हालांकि यह अनावश्यक GPU लोड में परिणाम देगा। यह एक ऐसा ही मुद्दा है

सही है, लेकिन यह समस्या नहीं है, जो निष्क्रिय होने पर भी सीपीयू उपयोग है।

@ efroim102 https://github.com/Microsoft/vscode/issues/22900#issuecomment -288832322

हे प्रिय देवताओं, यह बहस हलकों में जाएगी जब तक यह तय नहीं हो जाता कि लक्ष्य क्या है:

1. बैटरी की खपत कम करें
2. सीपीयू विवाद को कम करें

पल के लिए मान लें (1)। तब हम इस बारे में थोड़ा अधिक डेटा-चालित हो सकते हैं कि क्या सीपीयू से जीपीयू को इस तरह के काम के बोझ के साथ उतारना (ए) समान मात्रा में ऊर्जा का उपयोग करता है, (बी) कम ऊर्जा का उपयोग करता है, या (सी) अधिक ऊर्जा का उपयोग करता है। मुझे इन मामलों में कोई विशेषज्ञता नहीं है, इसलिए मैं यह अनुमान नहीं लगा सकता कि यह सच है।

हालांकि, मान लें कि GPU ऑफलोड (b) की ओर जाता है; सही नहीं होने पर, व्यापार-मार्ग इस मार्ग को आगे बढ़ाने के लिए पर्याप्त स्वीकार्य हो सकता है, जबकि क्रोमियम अपने अंतर्निहित मुद्दे को संबोधित करता है। हालांकि, अगर VSCode की टीम ने इसे एक बार और सभी के लिए ठीक करना आवश्यक समझा, तो ऑफलोड एक असंभावित विकल्प होगा, और दीर्घकालिक फिक्स का पीछा करना (भले ही इसमें काफी समय लगे) बेहतर है। कम से कम मेरी तुच्छ राय में, मेरे लिए यह जानना काफी अच्छा होगा कि इस समस्या पर ध्यान दिया गया है और यह तब प्राथमिकता पर होगा जब निर्भरताएं निर्धारित फ़िक्स को सक्षम करें।

(मुझे यकीन है कि मैंने कुछ सूक्ष्म विवरणों को भ्रमित किया है कि क्या समाधान उपलब्ध / अवरुद्ध हैं, लेकिन यह लिखने में उम्मीद है कि लोग इस बात पर ध्यान केंद्रित कर सकते हैं कि समाधान की जगह में छलांग लगाने के बजाय वे किस समस्या को हल करने की उम्मीद कर रहे हैं।)

क्या जीपीयू बेहतर नहीं होगा जो किसी भी तरह से रेंडरिंग लोड से निपटने के लिए सुसज्जित होगा? यह वही है जो इसके लिए बनाया गया था।

सहमत, हम प्राथमिकता देते हैं कि सीपीयू और जीपीयू का अलग-अलग उपयोग क्या है, ग्राफिक्स-संबंधित सुविधा का उपयोग ग्राफिक्स-विशिष्ट संसाधनों का उपयोग करने से अधिक समझ में आता है। सीपीयू का एक लाभ GPU का 1: 1 नुकसान नहीं है, और इसके विपरीत। इस बिंदु पर ज्यादातर मूट (क्रोमियम में बग को पैच किए जाने तक) लेकिन वर्तमान समाधान के रूप में कुछ हद तक प्रासंगिक अभी भी सीपीयू को नियुक्त करता है (यद्यपि बहुत कम वजन के साथ)।

मुझे लगता है कि लोगों को डेस्कटॉप पर वेब तकनीक का उपयोग करना बंद कर देना चाहिए, क्योंकि इसके लिए प्रत्येक प्रोग्राम के साथ पूरी तरह से विकसित ब्राउज़र की शिपिंग की आवश्यकता होती है।
इस बात का उल्लेख नहीं है कि, यदि आपके पास उक्त कार्यक्रमों में से कई हैं, तो आपके पास सभी जगह एक ही बायनेरिज़ डुप्लिकेट हैं।

हमें नंगे धातु पर वापस जाने की आवश्यकता है।

पुनश्च: JScript को 10 साल पहले खोदना चाहिए था, जैसे Obj-C होना चाहिए था, Apple ने इसे फिर से नहीं बनाया।
PPS: ^ ^ ^ ^ ^ यह एक शेख़ी है।

PPS: ^ ^ ^ ^ ^ यह एक शेख़ी है।

@ bit2shift वास्तव में यह है, और इस तरह यह एक बहुत विशिष्ट बग के बारे में टिप्पणी धागा में नहीं है। कृपया रेंट के लिए GitHub मुद्दे टिप्पणियों का उपयोग न करें।

@ bit2shift - जबकि मैं कुछ हिस्सों से सहमत हूं (जैसे कि एक ब्राउज़र-आधारित ऐप शायद एक सच्चे देशी ऐप की तुलना में काफी "देशी" महसूस नहीं करेगा), हालांकि निम्न-स्तर "नंगे धातु" है? मशीन कोड? सभा की भाषा? सी? सी ++? सी#? आपकी तकनीक स्टैक की परवाह किए बिना हमेशा एब्सट्रैक्शन की कई परतें होने वाली हैं।

इस बात का उल्लेख नहीं है कि, यदि आपके पास उक्त कार्यक्रमों में से कई हैं, तो आपके पास सभी जगह एक ही बायनेरिज़ डुप्लिकेट हैं।

यह किसी भी C # ऐप के साथ ऐसा ही है जो NuGet पैकेज का उपयोग करता है। सभी असेम्बल ऐप के लिए स्थानीय हैं। .NET कोर यहां तक ​​कि ढांचे के बड़े हिस्से को NuGet पैकेज के रूप में वितरित करता है।

के रूप में यह प्रत्येक कार्यक्रम के साथ एक पूरी तरह से विकसित ब्राउज़र शिपिंग की आवश्यकता है।

तकनीकी रूप से आप एज इंजन का उपयोग कर सकते हैं, जो एक अलग ब्राउज़र रनटाइम स्थापित करने की आवश्यकता से बचना होगा। Internet Explorer ने HTML अनुप्रयोगों के साथ लगभग 20 साल पहले कुछ ऐसा ही किया था । एक अन्य उदाहरण रिएक्ट नेटिव है, जो जहां उपलब्ध है वहां ओएस के मूल जेएस इंजन का उपयोग करता है। जावास्क्रिप्ट-आधारित ऐप्स के लिए, विंडोज के लिए रिएक्ट नेटिव जैसा कुछ संभवतः वेब प्रौद्योगिकियों के बजाय भविष्य है, क्योंकि यह अधिक देशी लगता है क्योंकि यह मूल यूआई विजेट का उपयोग करता है।

@ Daniel15

(...) हालांकि निम्न-स्तर "नंगे धातु" कैसे है? मशीन कोड? सभा की भाषा? सी? सी ++? सी#?

कोई भी भाषा जो मशीन कोड के लिए अनिवार्य है (केवल source -> ELF/PE मायने रखता है) को इस संदर्भ में "नंगे धातु" माना जाता है, इसलिए यहां अमूर्त की परतें मायने नहीं रखती हैं।

Internet Explorer ने HTML अनुप्रयोगों के साथ लगभग 20 साल पहले कुछ ऐसा ही किया था।

"कुछ ऐसा ही" जैसा कि mshtml.dll 90 के बाद से सिस्टम32 में रहने वाले mshta.exe mshtml.dll करता है।

एक अन्य उदाहरण रिएक्ट नेटिव है, जो जहां उपलब्ध है वहां ओएस के मूल जेएस इंजन का उपयोग करता है। जावास्क्रिप्ट-आधारित ऐप्स के लिए, विंडोज के लिए रिएक्ट नेटिव जैसा कुछ संभवतः वेब प्रौद्योगिकियों के बजाय भविष्य है, क्योंकि यह अधिक देशी लगता है क्योंकि यह मूल यूआई विजेट का उपयोग करता है।

यदि डेस्कटॉप जेएस एप्लिकेशन में उच्च प्रदर्शन वांछित है, तो किसी के हाथों में पर्याप्त समय एलएलवीएम के लिए एक दृश्य लिखना चाहिए।
आप कोड के मनमाने स्निपेट्स को चलाने की क्षमता खो देंगे, लेकिन यह एक सुरक्षा दृष्टिकोण से एक फायदा होगा।

/ धागा

क्या आप इस धागे को पटरी से नहीं उतार सकते? यह ब्लिंकिंग कर्सर के साथ एक विशिष्ट प्रदर्शन के मुद्दे के बारे में एक मुद्दा है और यह निश्चित रूप से जेएस-आधारित डेस्कटॉप एप्लिकेशन को विकसित करने के सामान्य गुणों पर चर्चा करने के लिए जगह नहीं है।

आप उन लोगों के मेलबॉक्सों को केवल स्पैम कर रहे हैं, जिन्हें इन रैंट्स में कोई दिलचस्पी नहीं है।

कैसे के बारे में <input type=text> 2px * 10px आकार के साथ <input> : P <blink></blink> way के मूल ब्लिंकिंग कर्सर का उपयोग करेगा

इसके अलावा, मुझे यकीन नहीं है कि यह मुद्दा कितना गंभीर है, जब VSCode बेकार है (मैं कोड नहीं लिख रहा हूं) यह लगभग हमेशा फोकस में नहीं होता है, फोकस अन्य एप्लिकेशन में होता है, और कर्सर ब्लिंक करना बंद कर देता है।

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

मास्टर और रिलीज़ / 1.11 (सीएसएस एनीमेशन -> setInterval ) के लिए टर्मिनल कर्सर परिवर्तन को धक्का दिया।

इस मुद्दे को देखने के लिए आप सभी का धन्यवाद। आपकी जांच और सुझावों ने हमें मूल कारण और संभावित समाधान खोजने में मदद की! हमने जावास्क्रिप्ट setInterval , एनिमेटेड gif और कई अन्य तकनीकों की तुलना की, और हम निम्नलिखित समाधान पर बसे:

• तो editor.cursorBlinking के लिए सेट है blink या terminal.integrated.cursorBlinking के लिए सेट है true , निमिष तर्क अब जावास्क्रिप्ट में कार्यान्वित किया जाता। हमारे परीक्षण से पता चलता है कि CPU उपयोग 1% से कम हो जाता है।
• यदि editor.cursorBlinking smooth , expand या phase उपयोग किया जाता है, जो CSS सहजता कार्यों का उपयोग करते हैं, तो हम कर्सर के निष्क्रिय होने के बाद ब्लिंकिंग एनीमेशन को रोक देंगे। दस पल।

यह फिक्स पहले से ही हमारे इनसाइडर बिल्ड में है और यह हमारे अप्रैल स्टेबल बिल्ड में उपलब्ध होगा जो अगले कुछ दिनों में रिलीज़ किया जाएगा। यह बहुत अच्छा होगा यदि आप में से कुछ हमारे परीक्षा परिणामों को सत्यापित कर सकते हैं। यदि आप समस्याएँ देखते हैं, तो कृपया एक नया मुद्दा बनाएँ।

@rebornix क्या आपके कहने का मतलब "या" terminal.integrated.cursorBlinking true ? या "और" जानबूझकर था?

@jedmao सुधार के लिए धन्यवाद, यह or होना चाहिए।