Eine Problemumgehung für Leute, die ebenfalls von der Akkulaufzeit besessen sind: Wenn Sie das Blinken des Cursors deaktivieren, sinkt die CPU-Auslastung auf 0. Hier ist die Einstellung:

  "editor.cursorBlinking": "solid"

Einige Leute auf Twitter sagten, sie könnten dies nicht reproduzieren, deshalb habe ich eine Zeitleiste in den Entwicklertools aufgezeichnet, um das Debuggen zu erleichtern.

TimelineRawData-20170321T114212.json.zip

• Screenshot der Timeline:

  

• Wenn wir in ein einzelnes Bild zoomen, sehen wir, dass der Haupt-Thread beim Rendern von nur 2 fps einige Arbeiten mit 60 fps (alle 16 ms) ausführt - die dünnen Linien sind mit Pfeilen markiert:

  

• Wenn Sie den gesamten Weg in eine dieser dünnen Linien hineinzoomen, sehen Sie, dass einige Rendervorgänge mit 60 fps ausgeführt werden:

  

• Wenn ich ein CPU-Profil nehme, wird angezeigt, dass die meiste CPU in "(Programm)" verbraucht wird, nicht in einer bestimmten JS-Funktion.

  

• Wenn ich "editor.cursorBlinking": "solid" setze, verschwindet das Problem größtenteils: Ein periodischer "Layer Tree aktualisieren" / "Paint" / "Composite Layers" wird immer noch ausgeführt, jedoch nur alle 500 ms, nicht alle 16 ms.

Ich hoffe das hilft!

@joliss Schnelle Antwort auf das, was unter der Haube passiert: Eine native Animation wird bei 60 Hz in Chromium aktualisiert.

Ähnliches (fast gleiches) Chromium-Problem https://bugs.chromium.org/p/chromium/issues/detail?id=500259 und Chromiums Tracking-Element https://bugs.chromium.org/p/chromium/issues/detail id = 361587

Unsere aktuelle CSS-Animation

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

Aktualisieren

Zitiert Paul Irish (Chrome-Typ) https://news.ycombinator.com/item?id=13941293

Leistungsstarke * Texteditoren, die auf dem Webstack basieren, können sich nicht auf das OS-Text-Caret verlassen und müssen ihre eigenen bereitstellen.
In diesem Fall verwendet VSCode wahrscheinlich den vernünftigsten Ansatz zum Blinken eines Cursors: eine step Timing-Funktion mit einer CSS-Keyframe-Animation. Dies weist den Browser an, die Deckkraft nur alle 500 ms zu ändern. In der Zwischenzeit hat Chrome dies noch nicht vollständig optimiert, daher http://crbug.com/361587.
Derzeit führt Chrome alle 16 ms den gesamten Rendering-Lebenszyklus (Stil, Farbe, Ebenen) durch, wenn dies nur im Abstand von 500 ms erfolgen soll. Ich bin zuversichtlich, dass die Ingenieure, die an den Stilkomponenten von Chrome arbeiten, dies klären können, aber es wird ein wenig Arbeit erfordern. Ich denke, die zusätzliche Sichtbarkeit zu diesem Thema wird wahrscheinlich die Priorität des Fixes erhöhen. :) :)

• Einfache und grundlegende Texteditoren, die auf [contenteditable] basieren, können dies, aber diese lassen sich selten auf die am meisten gewünschten Funktionen skalieren.

Wird sich diese Änderung der CPU-Auslastung von Chrom-Tabs im Hintergrund auf den Editor auswirken?

Hoffentlich nicht (siehe https://github.com/electron/electron/issues/7553). Wir setzen backgroundThrottling schon seit false .

Vielen Dank an @joliss @rebornix für die nette Analyse.

Sieht so aus, als sollten wir unter OSX wieder setInterval .

ps Hier ist die anfängliche Cursor-Blinklogik :)

@rebornix Hier ist ein ähnliches Problem, auf das wir vor https://bugs.chromium.org/p/chromium/issues/detail?id=658894. In unserem Fall bestand die Problemumgehung darin, das animierende Element aus dem DOM zu entfernen, wenn es nicht verwendet wurde, anstatt es nur zu verschließen.

Link zur aktuellen Implementierung -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

Es gibt auch einen CSS-Stil für das gleiche, nicht sicher, ob es hier verwendet wird -

<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

Warum nicht https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback für die Cursoranimation verwenden?

Verwenden Sie pageVisibility- APIs, mit denen Sie wissen, wann die Seite ausgeblendet ist, um die Animation zu deaktivieren.

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

Vorschläge hier zum Rendern der CSS-Animation mit der GPU anstelle der CPU:

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

Wenn der Editor in der aktuellen Implementierung den Fokus verliert, wird die Animation entfernt, damit das Leben einfacher wird. Wenn der Editor jedoch den Fokus hat, bedeutet dies, dass der Editor sichtbar (nicht ausgeblendet oder im Hintergrund) und aktiv ist. Benutzer arbeiten daran (Lesen ist ein guter Fall), lösen jedoch keine Ansichts- / Inhaltsänderungen aus. In diesem Fall müssen wir den blinkenden Cursor immer noch anzeigen, obwohl er sich im Leerlauf befindet. Genau das ist ein blinkender Cursor.

Diese Funktion ist zunächst in JavaScript implementiert und vor etwa einem Jahr haben wir auf CSS-Animation umgestellt. Wie bereits bei @alexandrudima erwähnt, möchten wir möglicherweise unter OSX zu JS zurückkehren.

@camwest, dass API charmant ist, der einzige Haken ist Kompatibilität (leider Safari).

@mehas will-change ist vielversprechend. Ich habe es versucht, aber Chromium optimiert in diesem Fall nicht. Wenn Sie in Dev Tools die Option Paint Flashing aktivieren, können Sie sehen, dass dieser blinkende Cursor überhaupt nicht neu gezeichnet wird.

@jlukic @bcherny danke für deine Vorschläge. Das, was wir optimieren möchten, ist, wenn der Cursor sichtbar, aktiv und blinkend ist. Daher haben wir dieses Problem immer noch, obwohl wir eine Sichtbarkeitsprüfung haben. Aber Sie haben Recht, wir sollten die Sichtbarkeit überprüfen. Wenn Sie jetzt durch das Fenster scrollen, um den blinkenden Cursor unsichtbar zu machen, haben wir keine Optimierung.

Um fair zu sein, Monaco ist wirklich sehr, sehr, sehr komplex. :) :)

@rebornix will-change hat für mein Projekt funktioniert, die CPU-Nutzung ist komplett verschwunden. Meine Keyframes ändern jedoch nicht die Deckkraft. Stattdessen ändern sie die Farbe des Elements von "erben" in "transparent".

Ich bin nur ein Lurker, und es tut mir leid, wenn dies als Fluchen angesehen wird, aber würde ein animiertes GIF mit zwei Bildern nicht den Trick tun? Ich bin mir nicht ganz sicher, wie ich das abschließend testen soll, aber ich könnte mir vorstellen, dass sogar KHTML bereits optimierte Pfade dafür hatte, lange bevor es sich in Chrome verwandelte.

@eteeselink wäre interessant zu sehen, aber die

@matthiasg Ahyes, Zoom vergessen.

Andernfalls sollte die automatische Generierung eines blinkenden GIF basierend auf der Themenfarbe nicht zu schwierig sein. Es geht wahrscheinlich darum, ein paar Bytes in eine vorgebackene Datei zu patchen, da GIF-Pixeldaten zwar LZW-codiert sind, die Palettendaten jedoch nicht komprimiert sind. Aber ich wette, das Zoomen eines solchen Gifs macht es verschwommen, also ist dies vielleicht trotzdem ein schlechter Ansatz.

Wenn jemand eine Möglichkeit finden kann, das Zoomen eines GIF-Carets nicht zum Kotzen zu bringen, verspreche ich, Code beizutragen, der eine Farbe annimmt und eine animierte GIF-Daten-URL mit blinkendem Caret erzeugt.

@eteeselink Sie sollten das in Vanilla JS sowieso unbedingt sagen, vielleicht auch PHP und ein paar andere Geschmacksrichtungen. Ich kann mir vorstellen, dass es im gesamten Web mehrere Tonnen nutzen würde, und dann sind Sie sehr berühmt, wenn Sie eine Lizenz verwenden, für die der ursprüngliche Autor anerkannt werden muss.

@eteeselink Wenn wir Lösungen von der Wand vorschlagen, warum wickeln wir das Karat nicht stattdessen in <blink></blink> ein? :zwinkern:

Bitte unterlassen Sie es, sich der Reddit-Brigade anzuschließen, um nutzlose Kommentare zu Themen und PRs abzugeben, bei denen die Leute versuchen, echte Verbesserungen vorzunehmen.

Wenn der Editor den Fokus hat, bedeutet dies, dass der Editor sichtbar ist

Dies ist eine falsche Annahme. Es ist trivial, ein Fenster über ein anderes zu heben, ohne es zu fokussieren. Zwei Möglichkeiten, die ich kenne:

• der WM-Hinweis "Immer oben drauf zeichnen"
• Wenn ein Fenster zwischen virtuellen Desktops verschoben wird (da die Stapelreihenfolge global ist und ein Fenster auf dem vorherigen Desktop an erster Stelle stand, befindet es sich möglicherweise nicht auf dem neuen).

Beide sind für sich genommen sehr häufig, verursachen jedoch nicht immer Probleme.

@ o11c danke, meine

Ich denke, setTimeout oder setInterval passen wahrscheinlich besser zu diesem Anwendungsfall als requestIdleCallback. Das Timing von requestIdleCallback ist nicht vorhersehbar, und die Arbeit, die Sie in JS ausführen, ist kostengünstig. Ich denke, Sie sollten besser nur seltene Timer einplanen.

Ex. https://gist.github.com/esprehn/afec30fbc655bba6bb8f3f67c28beef4

Bemerkenswert ist auch, dass diese Caret-Animation einen glatten Impulseffekt ausführt, aber der Systemcursor in Browsern (z. B. der in einem <input> oder <textarea> ) nur ein binäres Ein / Aus ausführt . Native Steuerelemente auf Mac und Linux blinken stattdessen ähnlich. Es ist weniger hübsch, würde aber erheblich weniger Strom verbrauchen.

Danke @esprehn , genau das habe ich gerade getan, um flach zu blinken. Und wie Sie bereits erwähnt haben, ist es nicht so hübsch wie eine Animation, nicht einmal zu sagen, dass blinkende Cursor, die ease-in-out , glatt / erweitert sind.

warte @eteeselink ,

Beispiel: https://jsfiddle.net/mrkev/stxq613s/1/

Ich hoffe, diesen animierten Blink-Caret-Generator bald zu sehen;)

@mrkev Ihr 1px-GIF als Daten uri: data: image / gif; base64 , R0lGODlhAQABAPAAAAAAAP

@rmacfadyen süß! Da Gifs theoretisch eine Farbtabelle verwenden, sollten die 3 Bytes, die das Pixelschwarz im "Ein" -Rahmen färben, nicht zu schwer zu finden sein (sie werden nicht im Rahmen gespeichert, sodass Sie wahrscheinlich nicht zu tief über den Header hinausgehen müssen ). Wenn ich morgen etwas Freizeit finde, kann ich auch tiefer in sie eintauchen

Welp, der sowieso Schlaf braucht, beschloss, dies etwas weiter zu erforschen. Da Gifs eine globale Farbtabelle verwenden , die immer mit dem 14. Byte beginnt, war es nicht schwer herauszufinden, wie die Farbe geändert werden kann. Dies machte dieses blinkende Pixel-GIF rot:

Was jetzt wirklich ärgerlich ist, ist, dass in base64 jede Ziffer nur 6 Bit codiert, sodass die Dinge nicht richtig ausgerichtet sind. Es sind die niedrigstwertigen Bits von Ziffer 18 bis zu den höchstwertigen Bits von Ziffer 22, die die Farbe Schwarz in diesem GIF codieren. Im Wesentlichen wird also eine gewisse Permutation von Zeichen [A-P] [A-/] [A-/] [A-/] [P,f,v,/] in Position 18-22 dieses Pixel in jeder Farbe zeichnen.

Hier ist ein Beispiel für dieses GIF in einer zufälligen Farbe. Ich habe im Wesentlichen nur das ersetzt, was in den Zeichen 18-22 enthalten war, durch G8ABf (was den Kriterien entspricht, von denen ich oben spreche).

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

Sollte nicht schlecht sein, um eine Funktion zu erstellen, die RGB verwendet und dieses GIF in dieser Farbe zurückgibt (:

Ich habe Unterricht in 7 Stunden. Ich spiele buchstäblich nur mich selbst.

Aber wie auch immer, ich erkannte, dass jemand wahrscheinlich bereits eine Hex-to-Base64-Funktion geschrieben hatte und eine schnelle Stackoverflow- Suche ausreichte, um sie zu finden. Also hier ist die Funktion;

// 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(""))
}

Gute Nacht alle zusammen!

Verdammt, @mrkev hat mich geschlagen. Wie auch immer, hier ist meine Implementierung derselben Sache:
https://jsfiddle.net/a6g4ob7h/

Es könnte etwas schneller sein, da kein Matching und Mapping stattfindet, sondern nur ein Btoa. Aber ich bezweifle, dass Geschwindigkeit wichtig ist, und es ist besser, das Ergebnis zwischenzuspeichern.

Ich frage mich wirklich, ob dies die Dinge überhaupt beschleunigt. Ich habe kein gutes Setup zum Testen, aber wer weiß, vielleicht werden animierte Gifs auch mit 60 fps neu gerendert.

Wenn Sie zoomen möchten und keinen rechteckigen Cursor haben möchten, können Sie auch animiertes SVG verwenden. (Das <animate> -Element war bereits Teil der SVG 1.0-Spezifikation.)

@eteeselink Max sollte ungefähr 50 fps sein, http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

Für mich bleibt es die meiste Zeit auf 0 (CPU-Auslastung ist die erste Spalte - OSX 10.12.3 - MacBook Pro Retina, 15 Zoll, Ende 2013)

Ich habe Standardeinstellungen in Bezug auf den Cursor.

Da niemand Linux erwähnt hat, habe ich es bei GNOME Shell mit Wayland (Ivy Bridge Graphics) bei etwa 5-7%.

Wir haben gerade PR # 23121 zusammengeführt, um dies zu mildern, indem wir für den blinkenden Cursor-Stil blink auf setInterval . Auf dem mir zur Verfügung stehenden Mac mini sinkt die CPU-Auslastung von 5,9% auf 0,9%

Haben Sie jemals darüber nachgedacht, nativ zu werden und das Betriebssystem den Cursor kostenlos zur Verfügung stellen zu lassen?

@justjoeyuk Siehe Zitat von @rebornix oben, warum dies nicht möglich ist

@justjoeyuk Wenn Sie stattdessen eine vollständig native, nicht auf

AKTUELLE NACHRICHTEN! Microsoft stellt schrecklich codierte langsame Software her, wobei die Probleme unter MacOS 10 noch stärker ausgeprägt sind.

Wer hätte das jemals gedacht, oder?

@LandonPowell Sie verschmutzen die tatsächliche Diskussion über ein Problem. Die Reddit / Hackernews, die hier brigadieren, sind lächerlich.

Was ist mit dem Terminal-Cursor? Verursacht das auch Spitzen in den CPU-Zyklen?

@mehas

Vorschläge hier zum Rendern der CSS-Animation mit der GPU anstelle der CPU:

Dadurch wird das Problem nur ausgeblendet, indem die Last von der CPU auf die GPU verlagert wird. Es behebt es nicht wirklich.

@ Daniel15

Dadurch wird das Problem nur ausgeblendet, indem die Last von der CPU auf die GPU verlagert wird. Es behebt es nicht wirklich.

Die Belastung der CPU ist das Problem. Durch die Optimierung der Animation für die Verwendung der GPU wird dieses Problem behoben.

(Das ist getrennt von der Frage nach dem spezifischen Fix, den ich als den besten vorgeschlagen habe)

Ich bin mir nicht sicher, wie ich es reproduzieren soll. Ich benutze das Vim Emulation Plugin. Ich bin mir nicht sicher, ob es damit zusammenhängt.

Ich würde gerne wissen, wie das geht.

Durch die Optimierung der Animation für die Verwendung der GPU wird dieses Problem behoben.

Dies führt jedoch zu einer unnötigen GPU-Belastung. Dies ist ein ähnliches Problem, außer dass der Prozessor der Grafikkarte geladen ist. Es ist nicht wirklich eine Lösung 😛

Jesus wurde in Afrika geboren.

Bitte.

Warum nicht ein GIF für den Cursor verwenden?

Dies führt jedoch zu einer unnötigen GPU-Belastung. Das ist ein ähnliches Problem

Richtig, aber es ist nicht dieses Problem, das die CPU-Auslastung auch im Leerlauf betrifft.

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

Oh liebe Götter, diese Debatte wird sich im Kreis drehen, bis entschieden ist, was das Ziel ist:

1. Batterieverbrauch reduzieren
2. Reduzieren Sie CPU-Konflikte

Nehmen Sie für den Moment (1) an. Dann können wir etwas datengesteuerter darüber sein, ob das Auslagern von der CPU auf die GPU mit einer solchen Arbeitslast (a) dieselbe Energiemenge verbraucht, (b) weniger Energie verbraucht oder (c) mehr Energie verbraucht. Ich habe kein Fachwissen in diesen Angelegenheiten, daher kann ich nicht vorhersagen, was wahr ist.

Nehmen wir jedoch an, dass das GPU-Offload zu (b) führt; Obwohl dies nicht perfekt ist, kann der Kompromiss akzeptabel genug sein, um diesen Weg zu verfolgen, während / wenn Chromium das zugrunde liegende Problem angeht. Wenn das VSCode-Team es jedoch für notwendig hält, dies ein für alle Mal zu beheben, ist das Auslagern eine unwahrscheinliche Wahl, und das Streben nach einer langfristigen Behebung (auch wenn es eine Weile dauert) ist vorzuziehen. Zumindest meiner unbedeutenden Meinung nach ist es gut genug zu wissen, dass die Aufmerksamkeit auf dieses Problem gerichtet ist und dass es priorisiert wird, wenn Abhängigkeiten die beabsichtigte Lösung ermöglichen.

(Ich bin sicher, ich habe einige der subtilen Details darüber verwirrt, welche Lösungen verfügbar / blockiert sind, aber ich hoffe, dass sich die Leute darauf konzentrieren können, das Problem zu lösen, das sie lösen möchten, anstatt in den Lösungsraum zu springen.)

Wäre die GPU nicht besser für eine Rendering-Last gerüstet? Genau dafür wurde es gemacht.

Wir sind uns einig, dass wir Prioritäten setzen, was die CPU und die GPU unterschiedlich nutzt. Eine grafikbezogene Funktion, die grafikspezifische Ressourcen verbraucht, ist sinnvoller. Ein CPU-Gewinn ist kein 1: 1-Verlust der GPU und umgekehrt. Meistens strittig zu diesem Zeitpunkt (bis der Fehler in Chromium behoben ist), aber etwas relevant, da die aktuelle Lösung immer noch die CPU verwendet (wenn auch mit viel weniger Gewicht).

Ich denke, die Leute sollten aufhören, Web-Technologie auf dem Desktop zu verwenden, da für jedes Programm ein vollwertiger Browser ausgeliefert werden muss.
Ganz zu schweigen davon, dass Sie, wenn Sie mehrere dieser Programme haben, überall dieselben Binärdateien dupliziert haben.

Wir müssen zurück zu Bare Metal gehen.

PS: JScript hätte vor 10 Jahren fallen gelassen werden sollen, genau wie Obj-C, hätte Apple es nicht wiederbeleben sollen.
PPS: ^^^^ das ist ein Scherz.

PPS: ^^^^ das ist ein Scherz.

@ bit2shift In der Tat, und als solches gehört es nicht in den Kommentarthread über einen ganz bestimmten Fehler. Bitte verwenden Sie keine GitHub-Problemkommentare für Rants.

@ bit2shift - Obwohl ich einigen Teilen zustimme (wie der Tatsache, dass sich eine browserbasierte App im Vergleich zu einer echten nativen App wahrscheinlich nicht ganz "nativ" anfühlt), wie niedrig ist "Bare Metal"? Maschinensprache? Assemblersprache? C? C ++? C #? Unabhängig von Ihrem Technologie-Stack wird es immer mehrere Abstraktionsebenen geben.

Ganz zu schweigen davon, dass Sie, wenn Sie mehrere dieser Programme haben, überall dieselben Binärdateien dupliziert haben.

Dies gilt jedoch auch für alle C # -Apps, die NuGet-Pakete verwenden. Alle Assemblys sind lokal für die App. .NET Core verteilt sogar große Teile des Frameworks als NuGet-Pakete.

Da für jeden Programm ein vollwertiger Browser ausgeliefert werden muss.

Technisch gesehen könnten Sie die Edge-Engine verwenden, sodass keine separate Browser-Laufzeit installiert werden muss. Internet Explorer hat vor fast 20 Jahren etwas Ähnliches mit HTML-Anwendungen gemacht . Ein weiteres Beispiel ist React Native, das die native JS-Engine des Betriebssystems verwendet, sofern verfügbar. Bei JavaScript-basierten Apps ist React Native für Windows wahrscheinlich eher die Zukunft als Webtechnologien, da es sich nativer anfühlt, da es native UI-Widgets verwendet.

@ Daniel15

(...) Wie niedrig ist "Bare Metal"? Maschinensprache? Assemblersprache? C? C ++? C #?

Jede Sprache, die mit Maschinencode kompiliert werden kann (nur source -> ELF/PE zählt), wird in diesem Zusammenhang als "Bare Metal" betrachtet, daher spielen Abstraktionsebenen hier keine Rolle.

Internet Explorer hat vor fast 20 Jahren etwas Ähnliches mit HTML-Anwendungen gemacht.

"etwas Ähnliches" wie wenn mshta.exe mshtml.dll , das sich seit den 90er Jahren in system32 befindet.

Ein weiteres Beispiel ist React Native, das die native JS-Engine des Betriebssystems verwendet, sofern verfügbar. Bei JavaScript-basierten Apps ist React Native für Windows wahrscheinlich eher die Zukunft als Webtechnologien, da es sich nativer anfühlt, da es native UI-Widgets verwendet.

Wenn in Desktop-JS-Apps eine hohe Leistung gewünscht wird, sollte jemand mit genügend Zeit in den Händen ein Frontend für LLVM schreiben.
Sie würden die Fähigkeit verlieren, beliebige Codeausschnitte auszuführen, aber dies wäre aus Sicherheitsgründen ein Vorteil.

/Faden

Können Sie diesen Thread bitte nicht entgleisen? Dies ist ein Problem mit einem bestimmten Leistungsproblem mit einem blinkenden Cursor und definitiv kein Ort, um allgemeine Vorteile der Entwicklung von JS-basierten Desktop-Apps zu diskutieren.

Sie spammen nur Postfächer von Leuten, die nicht an diesen Beschimpfungen interessiert sind.

Wie wäre es, wenn Sie ein <input type=text> mit einer Größe von 2px * 10px an der Stelle platzieren, an der sich der Cursor befindet. Auf diese Weise wird der native blinkende Cursor von <input> : P <blink></blink> 👍 verwendet

Ich bin mir auch nicht sicher, wie schwerwiegend dieses Problem ist. Wenn VSCode inaktiv ist (ich schreibe keinen Code), ist es fast immer nicht scharf, der Fokus liegt auf einer anderen Anwendung, in der ich mich befinde. Und der Cursor hört auf zu blinken.

Nach meiner Erfahrung sind Gifs nicht so gut. Ich hatte einmal einen Ladespinner als GIF-Bild. und verwendet es während der Interaktion mit indexeddb. Manchmal konnte ich sehen, wie der Spinner anhielt, sogar auf dem Desktop.

Drückte den Terminal-Cursor auf Master und Release / 1.11 (CSS-Animation -> setInterval ).

Vielen Dank, dass Sie sich mit diesem Thema befasst haben. Ihre Untersuchungen und Vorschläge haben uns geholfen, die Grundursache und mögliche Lösungen zu finden! Wir haben JavaScript setInterval , animiertes GIF und verschiedene andere Techniken verglichen und uns für die folgende Lösung entschieden:

• Wenn editor.cursorBlinking auf blink oder terminal.integrated.cursorBlinking auf true , ist die Blinklogik jetzt in JavaScript implementiert. Unsere Tests zeigen, dass die CPU-Auslastung auf weniger als 1% sinkt.
• Wenn editor.cursorBlinking auf smooth , expand oder phase , die CSS-Beschleunigungsfunktionen verwenden, stoppen wir die blinkende Animation, nachdem der Cursor inaktiv ist 10 Sekunden.

Dieses Update befindet sich bereits in unserem Insider-Build und wird in unserem April Stable-Build verfügbar sein, der in den nächsten Tagen veröffentlicht wird. Es wäre großartig, wenn einige von Ihnen unsere Testergebnisse überprüfen könnten. Wenn Sie Probleme sehen, erstellen Sie bitte ein neues Problem.

@rebornix wolltest du sagen "oder" terminal.integrated.cursorBlinking ist auf true ? Oder war das "und" beabsichtigt?

@jedmao danke für die Korrektur, es sollte or .