حل بديل للأشخاص المهووسين أيضًا بعمر البطارية: تعطيل وميض المؤشر سيؤدي إلى انخفاض استخدام وحدة المعالجة المركزية إلى 0. إليك الإعداد:

  "editor.cursorBlinking": "solid"

قال بعض الأشخاص على Twitter إنهم لا يستطيعون إعادة إنتاج هذا ، لذلك ذهبت وسجلت جدولًا زمنيًا في Developer Tools للمساعدة في التصحيح.

الجدول الزمنيRawData-20170321T114212.json.zip

• لقطة شاشة للجدول الزمني:

  

• عند التكبير في إطار واحد ، نرى أنه بينما نعرض 2 إطارًا في الثانية فقط ، فإن الخيط الرئيسي يؤدي بعض الأعمال بمعدل 60 إطارًا في الثانية (كل 16 مللي ثانية) - الخطوط الرفيعة المميزة بالأسهم:

  

• بالتكبير بالكامل في أحد هذه الخطوط الرفيعة ، نرى أن بعض العرض يحدث بمعدل 60 إطارًا في الثانية:

  

• عندما آخذ ملف تعريف وحدة المعالجة المركزية ، فإنه يُظهر أن معظم وحدة المعالجة المركزية يتم إنفاقها في "(برنامج)" ، وليس أي وظيفة JS محددة.

  

• عندما قمت بتعيين "editor.cursorBlinking": "solid" ، تختفي المشكلة غالبًا: لا يزال يحدث "تحديث شجرة طبقة" / "طلاء" / "طبقات مركبة" ، ولكن كل 500 مللي ثانية ، وليس كل 16 مللي ثانية.

آمل أن يساعد هذا!

joliss إجابة سريعة على ما يحدث تحت الغطاء: تحديثات الرسوم المتحركة الأصلية عند 60 هرتز في Chromium.

مشكلة مماثلة (تقريبًا هي نفسها) Chromium https://bugs.chromium.org/p/chromium/issues/detail؟id=500259 وعنصر تتبع Chromium https://bugs.chromium.org/p/chromium/issues/detail ؟ معرف = 361587

الرسوم المتحركة الحالية لـ CSS

<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

لا يمكن أن تعتمد برامج تحرير النصوص القوية * المبنية على حزمة الويب على حرف الإقحام النصي لنظام التشغيل ويجب أن تقدم برامج التحرير الخاصة بها.
في هذه الحالة ، ربما يستخدم VSCode الطريقة الأكثر منطقية في وميض المؤشر: وظيفة توقيت step مع رسم متحرك لإطار مفتاح CSS. هذا يخبر المتصفح بتغيير العتامة فقط كل 500 مللي ثانية. في غضون ذلك ، لم يقم Chrome بتحسين هذا بالكامل حتى الآن ، ومن هنا http://crbug.com/361587.
حاليًا ، يقوم Chrome بدورة حياة العرض الكاملة (النمط والطلاء والطبقات) كل 16 مللي ثانية عندما يجب أن يقوم بهذا العمل فقط بفاصل زمني 500 مللي ثانية. أنا واثق من أن المهندسين الذين يعملون على مكونات نمط Chrome يمكنهم حل هذه المشكلة ، لكن الأمر سيستغرق القليل من العمل. أعتقد أن الرؤية المضافة حول هذا الموضوع ستؤدي على الأرجح إلى تصعيد أولوية الإصلاح. :)

• يمكن لمحرري النصوص البسيطة ، والمحررين الأساسيين المبنيين على [contenteditable] ، ولكن نادرًا ما يحتاجون إلى مجموعة الميزات.

هل سيؤثر هذا التغيير في استخدام وحدة المعالجة المركزية في الخلفية لعلامات تبويب الكروم على المحرر؟

لا نأمل (انظر https://github.com/electron/electron/issues/7553). لقد قمنا بتعيين backgroundThrottling إلى false منذ فترة بالفعل.

شكرًا لك @ jolissrebornix على التحليل الجميل.

يبدو أننا يجب أن نعود إلى استخدام setInterval على OSX.

ملاحظة: هذا هو منطق المؤشر الأولي الوامض :)

rebornix إليك مشكلة مماثلة واجهناها منذ فترة - https://bugs.chromium.org/p/chromium/issues/detail؟id=658894. كان الحل البديل في حالتنا هو إزالة العنصر المتحرك من DOM عندما لا يتم استخدامه ، بدلاً من حجبه فقط.

رابط التنفيذ الحالي -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

يوجد أيضًا نمط css لنفسه ، ولست متأكدًا من استخدامه هنا على الرغم من -

<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);

اقتراحات هنا لعرض الرسوم المتحركة لـ CSS باستخدام GPU بدلاً من وحدة المعالجة المركزية:

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

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

في البداية تم تنفيذ هذه الميزة في JavaScript وقبل عام واحد تقريبًا ، تحولنا إلى الرسوم المتحركة CSS. مثل alexandrudima المذكور ، قد نرغب في العودة إلى JS على OSX.

camwest أن api ساحر ، والصيد الوحيد هو التوافق (للأسف Safari).

mehas will-change واعد. لقد جربته ، لكن Chromium لا يتحسن في هذه الحالة. إذا قمت بتشغيل خيار Paint Flashing في Dev Tools ، يمكنك أن ترى أن هذا المؤشر الوامض لا تتم إعادة رسمه على الإطلاق.

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

لكي نكون منصفين ، موناكو معقدة حقًا حقًا. :)

rebornix will-change

أنا مجرد مخادع ، وآسف إذا كان هذا يعتبر سبباً ، لكن ألن تقوم الصورة المتحركة ذات الإطارين بالخدعة؟ لست متأكدًا تمامًا من كيفية اختبار هذا بشكل قاطع ، لكن يمكنني أن أتخيل أنه حتى KHTML لديها بالفعل مسارات محسّنة لذلك ، قبل وقت طويل من تحولها إلى Chrome.

سيكون من المثير للاهتمام رؤية eteeselink ، لكن لون المؤشر يحتاج إلى التغيير والتكبير وما إلى ذلك قد لا يكون تافهًا ، وقد يكون التبديل مرة أخرى إلى js في هذه الأثناء أسهل.

matthiasg Ahyes ، نسيت التكبير.

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

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

eteeselink يجب أن

eteeselink إذا كنا <blink></blink> بدلاً من ذلك؟ :غمزة:

يرجى الامتناع عن الانضمام إلى لواء Reddit في الإدلاء بتعليقات عديمة الفائدة على القضايا والعلاقات العامة حيث يحاول الناس إجراء تحسينات حقيقية.

إذا كان المحرر يركز ، فهذا يعني أن المحرر مرئي

هذا هو افتراض زائف. من السهل رفع نافذة فوق أخرى دون التركيز عليها. طريقتان أعرف عن:

• تلميح WM "الرسم دائمًا في المقدمة"
• عندما يتم نقل نافذة بين أسطح المكتب الافتراضية (نظرًا لأن ترتيب التراص عام ، إذا كانت النافذة في المقام الأول على سطح المكتب السابق ، فقد لا تكون على السطح الجديد).

كلاهما شائع جدًا بمفردهما ، على الرغم من أنهما لا يتسببان بالضرورة في حدوث مشكلات.

@ o11c شكرًا ، كان

أعتقد أن setTimeout أو setInterval هي على الأرجح أكثر ملاءمة لحالة الاستخدام هذه من requestIdleCallback. لا يمكن توقع توقيت requestIdleCallback ، والعمل الذي تقوم به في JS غير مكلف ، وأعتقد أنك ستكون أفضل حالًا بمجرد جدولة مؤقتات غير متكررة.

على سبيل المثال https://gist.github.com/esprehn/afec30fbc655bba6bb8f3f67c28beef4

وتجدر الإشارة أيضًا إلى أن حركة الإقحام هذه تؤدي تأثير نبضي سلس ، ولكن مؤشر النظام في المتصفحات (على سبيل المثال ، الموجود داخل <input> أو <textarea> ) يقوم فقط بتشغيل / إيقاف ثنائي . تعمل عناصر التحكم الأصلية في نظامي التشغيل Mac و Linux أيضًا على إجراء وميض بدلاً من ذلك. إنها أقل جمالًا ، لكنها ستستخدم طاقة أقل بكثير.

شكرًا esprehn ، هذا بالضبط ما فعلته من أجل الوميض المسطح الآن. ومثلما ذكرت ، فهي ليست جميلة مثل الرسوم المتحركة ، ولا حتى القول بسلاسة / توسيع المؤشرات الوامضة التي تستخدم ease-in-out .

انتظر eteeselink ، ألا تريد استخدام صورة GIF

مثال: https://jsfiddle.net/mrkev/stxq613s/1/

آمل أن أرى منشئ علامة الإقحام المتحركة هذا قريبًا ؛)

mrkev your 1px gif as data uri: data: image / gif؛ base64 ، R0lGODlhAQABAPAAAAAAAP /// yH / C05FVFNDQVBFMi4wAwEAAAAh + QQFMgABACwAAAAAAAAAQABAAACAUBACH

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

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

الأمر المزعج حقًا هو أنه في base64 يشفر كل رقم 6 بتات فقط حتى لا تتم محاذاة الأشياء بشكل صحيح. إنها الأجزاء الأقل أهمية من الرقم 18 حتى الرقم 22 الأكثر أهمية ترميز اللون الأسود في هذا 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. لكنني أشك في أن السرعة مهمة ، ومن الأفضل تخزين النتيجة مؤقتًا.

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

إذا كنت تريد التكبير / التصغير وليس لديك مؤشر مستطيل الشكل ، يمكنك أيضًا استخدام SVG متحرك. (كان العنصر <animate> جزءًا من مواصفات SVG 1.0.)

يجب أن يكون eteeselink Max حوالي 50 إطارًا في الثانية ، http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

بالنسبة لي ، فإنه يظل 0 معظم الوقت (استخدام وحدة المعالجة المركزية هو العمود الأول - OSX 10.12.3 - MacBook Pro Retina ، 15 بوصة ، أواخر 2013)

لدي إعدادات افتراضية فيما يتعلق بالمؤشر.

كما لم يذكر أحد Linux ، لدي حوالي 5-7٪ على GNOME Shell مع Wayland (Ivy Bridge Graphics).

لقد قمنا للتو بدمج PR # 23121 الذي يخفف من ذلك من خلال العودة إلى setInterval لنمط المؤشر الوامض blink . على جهاز Mac mini الذي أستخدمه تحت تصرفي ، ينخفض ​​استخدام وحدة المعالجة المركزية من 5.9٪ إلى 0.9٪

هل فكرت يومًا في الانتقال إلى اللغة الأصلية واستخدام نظام التشغيل الذي يوفر المؤشر مجانًا؟

justjoeyuk انظر اقتباس من rebornix أعلاه ، لماذا لا يمكن القيام بذلك

justjoeyuk إذا كنت تقترح بدلاً من ذلك

أخبار عاجلة! تصنع Microsoft برامج بطيئة بشكل فظيع ، مع ظهور المشكلات بشكل أكبر على نظام MacOS 10.

من كان ليخمن ، أليس كذلك؟

LandonPowell أنت تلوث المناقشة الفعلية حول قضية ما ؛ اللصقة reddit / hackernews هنا أمر سخيف.

ماذا عن مؤشر المحطة؟ هل يتسبب ذلك في حدوث طفرات في دورات وحدة المعالجة المركزية أيضًا؟

mehas

اقتراحات هنا لعرض الرسوم المتحركة لـ CSS باستخدام GPU بدلاً من وحدة المعالجة المركزية:

هذا يخفي المشكلة فقط عن طريق نقل الحمل من وحدة المعالجة المركزية إلى وحدة معالجة الرسومات. في الواقع لا يصلحه.

@ Daniel15

هذا يخفي المشكلة فقط عن طريق نقل الحمل من وحدة المعالجة المركزية إلى وحدة معالجة الرسومات. في الواقع لا يصلحه.

الحمل على وحدة المعالجة المركزية هي المشكلة، وتحسين الرسوم المتحركة لاستخدام GPU لا إصلاح هذه المشكلة.

(هذا منفصل عن مسألة الإصلاح المحدد الذي اقترحته أن يكون الأفضل)

لست متأكدًا حقًا من كيفية إعادة إنتاجه. أنا أستخدم البرنامج المساعد لمحاكاة vim. لست متأكدًا حقًا مما إذا كانت مرتبطة.

أود أن أعرف كيف ستسير الأمور.

يؤدي تحسين الرسوم المتحركة لاستخدام وحدة معالجة الرسومات إلى حل هذه المشكلة.

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

ولد يسوع في افريقيا.

على الرحب و السعة.

لماذا لا تستخدم gif للمؤشر؟

سيؤدي ذلك إلى تحميل GPU غير ضروري. هذه قضية مماثلة

صحيح ، لكنها ليست هذه المشكلة ، وهي استخدام وحدة المعالجة المركزية حتى في حالة الخمول.

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

يا الآلهة الأعزاء ، سوف يستمر هذا النقاش في حلقات حتى يتم تحديد الهدف:

1. تقليل استهلاك البطارية
2. تقليل تنازع وحدة المعالجة المركزية

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

ومع ذلك ، لنفترض أن إلغاء تحميل GPU يؤدي إلى (ب) ؛ في حين أنها ليست مثالية ، قد تكون المقايضة مقبولة بما يكفي لمتابعة هذا المسار أثناء / إذا كان Chromium يعالج مشكلته الأساسية. ومع ذلك ، إذا رأى فريق VSCode أنه من الضروري إصلاح هذا مرة واحدة وإلى الأبد ، فسيكون إلغاء التحميل خيارًا غير محتمل ، ويفضل السعي وراء الإصلاح طويل المدى (حتى لو استغرق الأمر بعض الوقت). على الأقل في رأيي غير المهم ، سيكون من الجيد بالنسبة لي أن أعرف أن الاهتمام بهذه المشكلة سيكون لها الأولوية عندما تتيح التبعيات الإصلاح المقصود.

(أنا متأكد من أنني أربكت بعض التفاصيل الدقيقة حول الحلول المتاحة / المحظورة ، ولكن آمل في كتابة هذا أن يركز الناس على تأكيد المشكلة التي يأملون في حلها بدلاً من القفز إلى مساحة الحل.)

ألن تكون وحدة معالجة الرسومات مجهزة بشكل أفضل للتعامل مع حمل العرض في كلتا الحالتين؟ هذا هو بالضبط ما تم صنعه من أجله.

متفق عليه ، نعطي الأولوية لما يستخدم وحدة المعالجة المركزية ووحدة معالجة الرسومات بشكل مختلف ، فوجود ميزة متعلقة بالرسومات تستخدم موارد خاصة بالرسومات أمر منطقي أكثر. لا يعتبر كسب وحدة المعالجة المركزية خسارة 1: 1 لوحدة معالجة الرسومات ، والعكس صحيح. غالبًا ما يتم مناقشته في هذه المرحلة (حتى يتم تصحيح الخطأ في Chromium) ولكنه مناسب إلى حد ما لأن الحل الحالي لا يزال يستخدم وحدة المعالجة المركزية (وإن كان وزنها أقل بكثير).

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

نحن بحاجة إلى العودة إلى المعدن.

ملاحظة: كان يجب التخلي عن JScript منذ 10 سنوات ، تمامًا كما كان ينبغي أن يكون Obj-C ، لو لم تقم Apple بإحيائه.
PPS: ^ ^ ^ ^ هذا تشدق.

PPS: ^ ^ ^ ^ هذا تشدق.

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

@ bit2shift - على الرغم من أنني أتفق مع بعض الأجزاء (مثل حقيقة أن التطبيق المستند إلى المتصفح قد لا يشعر بأنه "أصلي" تمامًا مقارنة بالتطبيق الأصلي الحقيقي) ، فما مدى المستوى المنخفض "bare metal" بالرغم من ذلك؟ كود الآلة؟ لغة التجميع؟ ج؟ C ++؟ C #؟ سيكون هناك دائمًا عدة طبقات من التجريد ، بغض النظر عن مجموعة التكنولوجيا الخاصة بك.

ناهيك عن أنه إذا كان لديك العديد من البرامج المذكورة ، فلديك نفس الثنائيات مكررة في كل مكان.

إنه نفس الشيء مع أي تطبيق C # يستخدم حزم NuGet بالرغم من ذلك. جميع التجميعات محلية للتطبيق. يقوم .NET Core بتوزيع أجزاء كبيرة من إطار العمل كحزم NuGet.

لأنه يتطلب شحن متصفح كامل مع كل برنامج.

من الناحية الفنية ، يمكنك استخدام محرك Edge ، والذي من شأنه تجنب الحاجة إلى تثبيت وقت تشغيل متصفح منفصل. فعل Internet Explorer

@ Daniel15

(...) ما هو المستوى المنخفض من "المعدن العاري"؟ كود الآلة؟ لغة التجميع؟ ج؟ C ++؟ C #؟

أي لغة يمكن تحويلها إلى كود الآلة (فقط source -> ELF/PE counts) تعتبر "مكشوفة" في هذا السياق ، لذلك طبقات التجريد لا تهم هنا

فعل Internet Explorer شيئًا مشابهًا منذ ما يقرب من 20 عامًا باستخدام تطبيقات HTML.

"شيء مشابه" مثل استخدام mshta.exe mshtml.dll الموجود في system32 منذ التسعينيات.

مثال آخر هو React Native ، والذي يستخدم محرك JS الأصلي لنظام التشغيل عند توفره. بالنسبة للتطبيقات المستندة إلى JavaScript ، من المحتمل أن يكون شيء مثل React Native for Windows هو المستقبل وليس تقنيات الويب ، لأنه يبدو أكثر أصالة لأنه يستخدم أدوات واجهة مستخدم أصلية.

إذا كان الأداء العالي مطلوبًا في تطبيقات سطح المكتب JS ، فيجب على أي شخص لديه وقت كافٍ أن يكتب واجهة أمامية لـ LLVM.
ستفقد القدرة على تشغيل مقتطفات عشوائية من التعليمات البرمجية ، لكن هذا سيكون ميزة من وجهة نظر الأمان.

/مسلك

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

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

ماذا عن وضع <input type=text> بحجم 2px * 10px في مكان المؤشر فيه. بهذه الطريقة ستستخدم المؤشر الوامض الأصلي لـ <input> : P <blink></blink> 👍

كما أنني لست متأكدًا من مدى خطورة هذه المشكلة ، فعندما يكون VSCode في وضع الخمول (أنا لا أكتب تعليمة برمجية) ، فإنه لا يتم التركيز عليه دائمًا ، ويكون التركيز على التطبيق الآخر الذي أستخدمه. ويتوقف المؤشر عن الوميض.

من تجربتي ، الصور المتحركة ليست جيدة. كان لدي مرة واحدة قرص تحميل كصورة gif. واستخدامها أثناء التفاعل مع indexeddb. في بعض الأحيان يمكنني رؤية القرص الدوار يتوقف ، حتى على سطح المكتب.

دفع تغيير المؤشر الطرفي إلى إتقان وإصدار / 1.11 (الرسوم المتحركة لـ CSS -> setInterval ).

شكرا لكم جميعا للنظر في هذه المسألة. ساعدتنا تحقيقاتك واقتراحاتك في العثور على السبب الجذري والحلول الممكنة! قارنا JavaScript setInterval و GIF المتحركة والعديد من التقنيات الأخرى ، واستقرنا على الحل التالي:

• إذا تم تعيين editor.cursorBlinking إلى blink أو terminal.integrated.cursorBlinking مضبوطًا على true ، يتم الآن تنفيذ المنطق الوامض في JavaScript. يُظهر اختبارنا انخفاض استخدام وحدة المعالجة المركزية إلى أقل من 1٪.
• إذا تم تعيين editor.cursorBlinking على smooth أو expand أو phase ، والتي تستخدم وظائف تسهيل CSS ، فسنوقف الحركة الوامضة بعد أن يصبح المؤشر خاملاً لـ 10 ثواني.

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

rebornix هل تقصد أن تقول "أو" terminal.integrated.cursorBlinking مضبوط على true ؟ أم كانت "و" مقصودة؟

jedmao شكرًا على التصحيح ، يجب أن يكون or .