Une solution de contournement pour les personnes qui sont également obsédées par la durée de vie de la batterie: la désactivation du clignotement du curseur entraînera une baisse de l'utilisation du processeur à 0. Voici le paramètre:

  "editor.cursorBlinking": "solid"

Certaines personnes sur Twitter ont dit qu'elles ne pouvaient pas reproduire cela, alors j'ai enregistré une chronologie dans les outils de développement pour aider au débogage.

TimelineRawData-20170321T114212.json.zip

• Capture d'écran de la chronologie:

  

• En zoomant sur une seule image, nous voyons que si nous ne rendons que 2 ips, le thread principal effectue un travail à 60 ips (toutes les 16 ms) - les lignes fines marquées de flèches:

  

• En zoomant complètement sur l'une de ces fines lignes, nous voyons que certains rendus se produisent à 60 ips:

  

• Lorsque je prends un profil de CPU, cela montre que la plupart des CPU sont dépensées dans "(programme)", pas dans une fonction JS spécifique.

  

• Quand je règle "editor.cursorBlinking": "solid" , le problème disparaît la plupart du temps: un "Update Layer Tree" / "Paint" / "Composite Layers" périodique se produit toujours, mais seulement toutes les 500 ms, pas toutes les 16 ms.

J'espère que ça aide!

@joliss Réponse rapide à ce qui se passe sous le capot: une animation native se met à jour à 60hz dans Chromium.

Problème similaire (presque le même) Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=500259 et l'élément de suivi de Chromium https://bugs.chromium.org/p/chromium/issues/detail ? id = 361587

Notre animation CSS actuelle

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

Mettre à jour

Citant Paul Irish (type Chrome) https://news.ycombinator.com/item?id=13941293

Les éditeurs de texte puissants * construits sur la pile Web ne peuvent pas s'appuyer sur le curseur de texte du système d'exploitation et doivent fournir le leur.
Dans ce cas, VSCode utilise probablement l'approche la plus raisonnable pour faire clignoter un curseur: une fonction step synchronisation http://crbug.com/361587.
Donc, actuellement, Chrome effectue le cycle de vie complet du rendu (style, peinture, calques) toutes les 16 ms alors qu'il ne devrait faire ce travail qu'à un intervalle de 500 ms. Je suis convaincu que les ingénieurs travaillant sur les composants de style de Chrome peuvent résoudre ce problème, mais cela prendra un peu de travail. Je pense que la visibilité supplémentaire sur ce sujet augmentera probablement la priorité du correctif. :)

• Les éditeurs de texte simples et les éditeurs de base basés sur [contenteditable] le peuvent, mais ceux-ci s'adaptent rarement à l'ensemble de fonctionnalités le plus recherché.

Ce changement concernant l'utilisation du processeur en arrière-plan des onglets chrome affectera-t-il l'éditeur?

Espérons que non (voir https://github.com/electron/electron/issues/7553). Nous ne fixons backgroundThrottling à false depuis un certain temps déjà.

Merci @joliss @rebornix pour la belle analyse.

On dirait que nous devrions revenir à l'utilisation de setInterval sur OSX.

ps Voici la logique initiale de clignotement du curseur :)

@rebornix Voici un problème similaire que nous avons rencontré il y a quelque temps - https://bugs.chromium.org/p/chromium/issues/detail?id=658894. La solution de contournement dans notre cas était de supprimer l'élément d'animation du DOM lorsqu'il n'était pas utilisé, plutôt que de simplement l'occulter.

Lien vers l'implémentation actuelle -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

Il existe également un style css pour le même, mais je ne sais pas s'il est utilisé ici -

<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

Pourquoi ne pas utiliser https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback pour l'animation du curseur?

Utilisez les API pageVisibility qui vous permettent de savoir quand la page est masquée pour désactiver l'animation.

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

Suggestions ici pour rendre l'animation CSS en utilisant le GPU au lieu du CPU:

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

Dans l'implémentation actuelle, si l'éditeur perd le focus, nous supprimerons l'animation pour que la vie soit facile. Cependant si l'éditeur a le focus, cela signifie que l'éditeur est visible (ni caché ni en arrière-plan) et actif, les utilisateurs y travaillent (la lecture est un bon cas) mais ne déclenchent aucun changement de vue / contenu. Dans ce cas, nous devons toujours afficher le curseur clignotant même s'il est un peu inactif , c'est ce qu'est un curseur clignotant.

Initialement, cette fonctionnalité est implémentée en JavaScript et il y a environ un an, nous sommes passés à l'animation CSS. Comme @alexandrudima l'a mentionné, nous souhaitons peut-être revenir à JS sur OSX.

@camwest que l'api est charmant, le seul hic est la compatibilité (malheureusement Safari).

@mehas will-change est prometteur. Je l'ai essayé, mais Chromium n'optimise pas dans ce cas. Si vous activez l'option Paint Flashing dans Dev Tools, vous pouvez voir que ce curseur clignotant n'est pas du tout repeint.

@jlukic @bcherny merci pour vos suggestions. Ce que nous voulons optimiser, c'est lorsque le curseur est visible, actif et clignote, nous avons donc toujours ce problème même si nous avons un contrôle de visibilité. Mais vous avez raison, nous devrions vérifier la visibilité. Pour le moment, si vous faites défiler la fenêtre pour rendre le curseur clignotant invisible, nous n'avons aucune optimisation.

Pour être honnête, Monaco est vraiment, vraiment, vraiment complexe. :)

@rebornix will-change a fonctionné pour mon projet, l'utilisation du processeur a complètement disparu. Cependant, mes images clés ne changent pas d'opacité. Au lieu de cela, elles changent la couleur de l'élément de «inherit» à «transparent».

Je suis juste un lurker, et désolé si cela est considéré comme un juron, mais un gif animé à deux images ne ferait-il pas l'affaire? Je ne suis pas tout à fait sûr de savoir comment tester cela de manière concluante, mais je pourrais imaginer que même KHTML avait déjà des chemins optimisés pour cela, bien avant qu'il se transgromorphe en Chrome.

@eteeselink serait intéressant à voir, mais la couleur du curseur doit changer et zoomer, etc. peut ne pas être trivial, revenir à js entre-temps pourrait être plus facile.

@matthiasg Ahyes, j'ai oublié le zoom.

Sinon, la génération automatique d'un GIF clignotant en fonction de la couleur du thème ne devrait pas être trop difficile. Il s'agit probablement de patcher quelques octets dans un fichier pré-cuit car, bien que les données de pixels GIF soient encodées en LZW, les données de la palette ne sont pas compressées. Mais je parie que zoomer sur un gif comme ça le rend flou, alors peut-être que c'est quand même une mauvaise approche.

Si quelqu'un peut trouver un moyen de faire en sorte que le zoom d'un caret gif ne soit pas nul, alors je promets de contribuer au code qui prend une couleur et produit une URL de données gif animée par un caret clignotant.

@eteeselink, vous devriez absolument

@eteeselink Si nous suggérons des solutions originales, pourquoi ne pas envelopper le carat dans <blink></blink> place? :clin d'œil:

Veuillez vous abstenir de rejoindre la brigade Reddit en faisant des commentaires inutiles sur des problèmes et des relations publiques où les gens essaient d'apporter de réelles améliorations.

si l'éditeur a le focus, cela signifie que l'éditeur est visible

C'est une hypothèse fausse. Il est trivial d'élever une fenêtre au-dessus d'une autre sans lui donner de concentration. Deux façons dont je connais:

• l'astuce WM "toujours dessiner en haut"
• lorsqu'une fenêtre est déplacée entre des bureaux virtuels (puisque l'ordre d'empilement est global, si une fenêtre était au premier plan sur le bureau précédent, il se peut qu'elle ne soit pas sur le nouveau).

Les deux sont très courants en eux-mêmes, bien qu'ils ne causent pas nécessairement toujours des problèmes.

@ o11c merci, mon hypothèse était trop sauvage lors de l'écriture. Oui, le focus ne signifie pas nécessairement visible, le défilement de la fenêtre est un cas (j'ai mentionné cela dans le même paragraphe :(). Je ne sais pas si focus + visible est le cas le plus courant mais tous devraient être atténués.

Je pense que setTimeout ou setInterval convient probablement mieux à ce cas d'utilisation que requestIdleCallback. Le timing de requestIdleCallback n'est pas prévisible, et le travail que vous faites dans JS est peu coûteux, je pense que vous feriez mieux de simplement programmer des minuteries peu fréquentes.

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

Il convient également de noter que cette animation caret fait un effet d'impulsion lisse, mais le curseur système dans les navigateurs (par exemple, celui à l'intérieur d'un <input> ou <textarea> ) ne fait qu'un binaire on / off . Les contrôles natifs sur Mac et Linux font de même un clignotement à la place. C'est moins joli, mais utiliserait beaucoup moins d'énergie.

Merci @esprehn , c'est exactement ce que j'ai fait pour le clignotement plat en ce moment. Et comme vous l'avez mentionné, ce n'est pas aussi joli que l'animation, pas même de dire des curseurs clignotants lisses / étendus qui utilisent ease-in-out .

attendez @eteeselink , ne voudriez-vous pas utiliser un gif 1px et le redimensionner quand même? Le flou ne devrait pas être un problème.

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

En espérant voir bientôt ce générateur de clignotement animé;)

@mrkev votre gif 1px en tant que données uri: data: image / gif; base64 , R0lGODlhAQABAPAAAAAAAP /// yH / C05FVFNDQVBFMi4wAwEAAAAh + QQFMgABACwAAAAAAAAQABAAACAkwBACH5BAUYAAAAABAC

@rmacfadyen doux! puisque les gifs utilisent une table de couleurs en théorie, les 3 octets qui colorent ce pixel en noir sur le cadre "on" ne devraient pas être trop difficiles à trouver (ils ne sont pas stockés dans le cadre, donc probablement pas besoin d'aller trop loin au-delà de l'en-tête ). Si je trouve du temps libre demain, je peux aussi m'y plonger plus profondément

Welp, qui a de toute façon besoin de sommeil, a décidé d'explorer cela un peu plus. Puisque les gifs utilisent une table de couleurs globale qui commence toujours au 14e octet, il n'a pas été difficile de comprendre comment changer la couleur. Cela a rendu ce pixel gif clignotant rouge:

Maintenant, ce qui est vraiment ennuyeux, c'est qu'en base64, chaque chiffre n'encode que 6 bits, donc les choses ne s'alignent pas correctement. Ce sont les bits les moins significatifs du chiffre 18 jusqu'au plus significatif du chiffre 22 qui encodent la couleur noire dans ce gif. Donc, essentiellement, une permutation de caractères [A-P] [A-/] [A-/] [A-/] [P,f,v,/] en position 18-22 dessinera ce pixel dans chaque couleur.

Voici un exemple de ce GIF sur une couleur aléatoire. J'ai essentiellement remplacé tout ce qui était dans les caractères 18-22 par G8ABf (qui correspond aux critères dont je parle ci-dessus).

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

Cela ne devrait pas être trop mauvais pour créer une fonction qui prend RVB et renvoie ce gif dans cette couleur (:

J'ai cours dans 7 heures, je joue littéralement juste moi-même.

Mais quoi qu'il en soit, j'ai réalisé que quelqu'un avait probablement déjà écrit une fonction hex-en-base64 et qu'une recherche rapide de stackoverflow était suffisante pour la trouver. Alors, voici la fonction;

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

Bonne nuit tout le monde!

Merde, @mrkev m'a battu. Quoi qu'il en soit, voici ma mise en œuvre de la même chose:
https://jsfiddle.net/a6g4ob7h/

Cela pourrait être un peu plus rapide car il n'y a pas de correspondance et de mappage en cours, juste un btoa. Mais je doute que la vitesse compte, et il vaut mieux cacher le résultat.

Ce que je me demande vraiment, c'est si cela accélère les choses. Je n'ai pas une bonne configuration à tester, mais qui sait, peut-être que les gifs animés sont également rendus à 60 ips.

Si vous souhaitez zoomer et ne pas avoir de curseur de forme rectangulaire, vous pouvez également utiliser le SVG animé. (L'élément <animate> faisait déjà partie de la spécification SVG 1.0.)

@eteeselink Max devrait être d'environ 50 ips, http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

Pour moi, il reste à 0 la plupart du temps (l'utilisation du processeur est la première colonne - OSX 10.12.3 - MacBook Pro Retina, 15 pouces, fin 2013)

J'ai des paramètres par défaut en ce qui concerne le curseur.

Comme personne n'a mentionné Linux, je l'ai à environ 5-7% sur GNOME Shell avec Wayland (Ivy Bridge Graphics).

Nous venons de fusionner le PR # 23121 qui atténue cela en revenant à setInterval pour le style de clignotement du curseur blink . Sur le mac mini que j'ai à ma disposition, l'utilisation du processeur passe de 5,9% à 0,9%

Avez-vous déjà envisagé de passer au mode natif et de demander au système d'exploitation de fournir le curseur gratuitement?

@justjoeyuk Voir la citation de @rebornix ci-dessus, expliquant pourquoi cela ne peut pas être fait

@justjoeyuk Si à la place vous suggérez une application entièrement native, non basée sur la pile Web: lorsque vous parcourez les besoins probables d'une application multiplateforme fortement thématique, entièrement indépendante du DPI, comme VSCode, il y a de fortes chances qu'un substitut de curseur non natif soit nécessaire indépendamment.

DERNIÈRES NOUVELLES! Microsoft fabrique des logiciels lents horriblement codés, les problèmes étant encore plus importants sur MacOS 10.

Qui aurait jamais deviné, non?

@LandonPowell Vous

Et le curseur du terminal? Cela provoque-t-il également des pics de cycles de processeur?

@mehas

Suggestions ici pour rendre l'animation CSS en utilisant le GPU au lieu du CPU:

Cela masque simplement le problème en déplaçant la charge du CPU vers le GPU. Cela ne résout pas vraiment le problème.

@ Daniel15

Cela masque simplement le problème en déplaçant la charge du CPU vers le GPU. Cela ne résout pas vraiment le problème.

La charge sur le processeur est le problème, l'optimisation de l'animation pour utiliser le GPU résout ce problème.

(C'est distinct de la question du correctif spécifique que j'ai suggéré d'être le meilleur)

Je ne sais pas vraiment comment le reproduire. J'utilise le plugin d'émulation vim. Je ne sais pas vraiment si c'est lié.

J'aimerais savoir comment cela se passe.

l'optimisation de l'animation pour utiliser le GPU résout ce problème.

Cela entraînera cependant une charge inutile du GPU. C'est un problème similaire, sauf que la charge est sur le processeur de la carte graphique. Ce n'est pas vraiment une solution 😛

Jésus est né en Afrique.

Vous êtes les bienvenus.

Pourquoi ne pas utiliser un gif pour le curseur?

Cela entraînera cependant une charge inutile du GPU. C'est un problème similaire

Bien, mais ce n'est pas ce problème, qui est l'utilisation du processeur même lorsqu'il est inactif.

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

Oh mes dieux, ce débat tournera en rond jusqu'à ce qu'il soit décidé quel est le but:

1. Réduisez la consommation de la batterie
2. Réduisez les conflits de processeur

Supposons (1) pour le moment. Ensuite, nous pouvons être un peu plus axés sur les données pour savoir si le déchargement du CPU vers le GPU avec une charge de travail comme celle-ci (a) utilise la même quantité d'énergie, (b) utilise moins d'énergie ou (c) utilise plus d'énergie. Je n'ai aucune expertise dans ces domaines, donc je ne peux pas prédire ce qui est vrai.

Cependant, supposons que le déchargement du GPU mène à (b); bien qu'il ne soit pas parfait, le compromis peut être suffisamment acceptable pour suivre cette voie pendant que / si Chromium résout leur problème sous-jacent. Cependant, si l'équipe VSCode juge nécessaire de résoudre ce problème une fois pour toutes, alors le déchargement sera un choix improbable et la poursuite du correctif à long terme (même si cela prend un certain temps) est préférable. Au moins à mon avis insignifiant, ce sera assez bien pour moi de savoir que l'attention est sur ce problème et qu'il sera priorisé lorsque les dépendances activeront le correctif prévu.

(Je suis sûr que j'ai confondu certains des détails subtils sur les solutions disponibles / bloquées, mais en espérant par écrit que les gens puissent se concentrer sur l'affirmation du problème qu'ils espèrent résoudre plutôt que de sauter dans l'espace des solutions.)

Le GPU ne serait-il pas mieux équipé pour gérer une charge de rendu de toute façon? C'est exactement ce pour quoi il a été conçu.

D'accord, nous priorisons ce qui utilise différemment le CPU et le GPU, il est plus logique qu'une fonctionnalité liée aux graphiques utilise des ressources spécifiques aux graphiques. Un gain de CPU n'est pas une perte 1: 1 de GPU, et vice-versa. Surtout sans objet à ce stade (jusqu'à ce que le bogue de Chromium soit corrigé), mais quelque peu pertinent car la solution actuelle utilise toujours le processeur (bien qu'avec beaucoup moins de poids).

Je pense que les gens devraient arrêter d'utiliser la technologie Web sur le bureau, car cela nécessite l'envoi d'un navigateur à part entière avec chaque programme.
Sans oublier que, si vous avez plusieurs de ces programmes, vous avez les mêmes binaires dupliqués partout.

Nous devons revenir au métal nu.

PS: JScript aurait dû être abandonné il y a 10 ans, tout comme Obj-C aurait dû l'être, si Apple ne l'avait pas ressuscité.
PPS: ^^^^ c'est une diatribe.

PPS: ^^^^ c'est une diatribe.

@ bit2shift En effet, et en tant que tel, il n'appartient pas au fil de commentaires sur un bogue très spécifique. Veuillez ne pas utiliser les commentaires sur les problèmes GitHub pour les diatribes.

@ bit2shift - Bien que je sois d'accord avec certaines parties (comme le fait qu'une application basée sur un navigateur ne se sentira probablement pas tout à fait "native" par rapport à une vraie application native), à ​​quel point le "bare metal" est-il de bas niveau? Langage machine? Langue d'assemblage? C? C ++? C #? Il y aura toujours plusieurs couches d'abstraction, quelle que soit votre pile technologique.

Sans oublier que, si vous avez plusieurs de ces programmes, vous avez les mêmes binaires dupliqués partout.

C'est la même chose avec toute application C # qui utilise des packages NuGet. Tous les assemblages sont locaux à l'application. .NET Core distribue même de grandes parties du framework sous forme de packages NuGet.

car il nécessite l'envoi d'un navigateur complet avec chaque programme.

Techniquement, vous pouvez utiliser le moteur Edge, ce qui éviterait d'avoir à installer un moteur d'exécution de navigateur distinct. Internet Explorer a fait quelque chose de similaire il y a près de 20 ans avec les applications HTML . Un autre exemple est React Native, qui utilise le moteur JS natif du système d'exploitation lorsqu'il est disponible. Pour les applications basées sur JavaScript, quelque chose comme React Native pour Windows est probablement l'avenir plutôt que les technologies Web, car il semble plus natif car il utilise des widgets d'interface utilisateur natifs.

@ Daniel15

(...) à quel point le "bare metal" est-il bas? Langage machine? Langue d'assemblage? C? C ++? C #?

Tout langage compilable en code machine (seulement source -> ELF/PE compte) est considéré comme "bare metal" dans ce contexte, donc les couches d'abstraction n'ont pas d'importance ici.

Internet Explorer a fait quelque chose de similaire il y a près de 20 ans avec les applications HTML.

"quelque chose de similaire" comme avoir mshta.exe utiliser mshtml.dll qui réside dans system32 depuis les années 90.

Un autre exemple est React Native, qui utilise le moteur JS natif du système d'exploitation lorsqu'il est disponible. Pour les applications basées sur JavaScript, quelque chose comme React Native pour Windows est probablement l'avenir plutôt que les technologies Web, car il semble plus natif car il utilise des widgets d'interface utilisateur natifs.

Si des performances élevées sont souhaitées dans les applications JS de bureau, une personne disposant de suffisamment de temps doit écrire une interface pour LLVM.
Vous perdriez la possibilité d'exécuter des extraits de code arbitraires, mais ce serait un avantage du point de vue de la sécurité.

/fil

Ne pouvez-vous pas faire dérailler ce fil, s'il vous plaît? Il s'agit d'un problème de performances spécifique avec un curseur clignotant et ce n'est certainement pas un endroit pour discuter des avantages généraux du développement d'applications de bureau basées sur JS.

Vous ne faites que spammer les boîtes aux lettres de personnes qui ne sont pas intéressées par ces diatribes.

Que diriez-vous de mettre un <input type=text> avec une taille de 2px * 10px à la place du curseur. De cette façon, il utilisera le curseur clignotant natif du <input> : P <blink></blink> 👍

De plus, je ne suis pas sûr de la gravité de ce problème, lorsque VSCode est inactif (je n'écris pas de code), il n'est presque toujours pas au point, le focus est sur l'autre application dans laquelle je suis. Et le curseur cesse de clignoter.

d'après mon expérience, les gifs ne sont pas si bons. Une fois, j'ai eu un spinner de chargement comme image gif. et l'a utilisé lors de l'interaction avec indexeddb. parfois je pouvais voir le spinner s'arrêter, même sur le bureau.

Poussé le changement de curseur de terminal sur master et release / 1.11 (animation CSS -> setInterval ).

Merci à tous d'avoir examiné cette question. Vos investigations et suggestions nous ont aidés à trouver la cause profonde et les solutions possibles! Nous avons comparé JavaScript setInterval , gif animé et plusieurs autres techniques, et nous avons opté pour la solution suivante:

• Si editor.cursorBlinking est défini sur blink ou terminal.integrated.cursorBlinking est défini sur true , la logique de clignotement est désormais implémentée en JavaScript. Nos tests montrent que l'utilisation du processeur chute à moins de 1%.
• Si editor.cursorBlinking est défini sur smooth , expand ou phase , qui utilisent les fonctions d'accélération CSS, nous arrêterons l'animation clignotante après que le curseur soit inactif 10 secondes.

Ce correctif est déjà dans notre build Insider et il sera disponible dans notre build April Stable qui sortira dans les prochains jours. Ce serait formidable si certains d'entre vous pouvaient vérifier les résultats de nos tests. Si vous voyez des problèmes, veuillez créer un nouveau problème.

@rebornix vouliez -vous dire "ou" terminal.integrated.cursorBlinking est défini sur true ? Ou le «et» était-il intentionnel?

@jedmao merci pour la correction, ça devrait or .