Blinkende cursor æder 13 procent af cpu-kraften

HTML, CSS og Javascript kan bruges til at lave desktop-applikationer, men det kan give uventede problemer viser bugs i Visual Studio Code og Chromium.

En cursor, der står og blinker på skærmen er det digitale modstykke til det blanke papir, som på én gang lokker med ubegrænsede muligheder og samtidig kan virke skræmmende. Og så kan cursoren bruge masser af cpu-kraft.

Eller det kan den i hvert fald i særlige tilfælde har både udviklerne af Microsofts Visual Studio Code og Googles Chromium opdaget.

En blinkende cursor burde ikke bruge ret meget cpu-kraft. Cursoren har trods alt været i stand til at blinke siden skærm og tastatur blev almindelige måder at interagere med computere på for mere end 40 år siden.

Og alligevel er der lige nu en bug i Visual Studio Code, som gør, at cursoren ser ud til at bruge op mod 13 procent af cpu'en på MacOS.

Den egentlige synder er, at cursoren blinker. Det er en grafisk animation, men hvorfor koster den så meget cpu-kraft i lige netop Visual Studio Code, når der i andre applikationer kan være blinkende cursorer, som ikke kan give et synligt udslag i cpu-forbruget?

Electron-applikation kan ikke forbinde direkte til styresystemets API'er

Visual Studio Code, som er en gratis tekst- og kodeeditor fra Microsoft, bygger - ligesom konkurrenten Atom - på Electron, der er et framework som kan bruges til at bygge applikationer ved hjælp af webteknologierne HTML, CSS og Javascript, der kan afvikles som 'native' desktop-applikationer.

Det betyder imidlertid, at en Electron-applikation ikke kan forbinde direkte til styresystemets API'er for eksempelvis tekstmarkører eller rendering af grafik på skærmen. Og det er dét, der giver en konflikt for applikationerne.

En bug i Chromium afspejler et problem, som minder om det i Visual Studio Code og formentligt er årsagen, da Electron, som Visual Studio Code bygger på, benytter Chromium til frontend-rendering.

I laget mellem HTML-renderingen og styresystemets rendering kan der opstå problemer. På MacOS, hvor fejlen i dette tilfælde er fundet, renderer styresystemet med en frekvens på 60 hertz, men den blinkende cursor er sat i Javascript/Typescript-koden til Visual Studio Code til at animere hvert 500 millisekund.

Da cursoren er et element, der skal animeres, så bliver den renderet ved hver frame af styresystemet, så selvom animationen kun skulle koste to frames pr. sekund, så koster den alligevel 60 frames pr. sekund, og ifølge Chromium-udviklerne har de ikke fundet en måde at undgå at rendere en ny frame, undtagen når cursoren skal skifte mellem tændt og slukket.

I dette tilfælde bliver alt i vinduet gentegnet i hver frame, og det er dét, der koster cpu-kraft. Problemet forsvinder, hvis man i CSS-koden til Visual Studio Code sætter markøren til ikke at blinke.

Frameworks som Electron er dukket op, fordi mange udviklere gerne vil kunne udvikle applikationer, som kan køre på tværs af forskellige styresystemer. Da webteknologier som HTML og Javascript i forvejen er beregnet til at være ligeglad med platformen nedenunder browseren, og mange udviklere kender HTML i forhold til de måder at opbygge grafiske grænseflader på, som bruges af eksempelvis Objective-C på MacOS, så er det nærliggende at bruge dem til 'native apps'.

De er dog ikke ægte native apps, men kræver et mellemlag, og det kan give problemer som dette konkrete problem med den blinkende markør.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Joachim Michaelis

Jeg synes der er en generel tendens i nutidens kode til, at vi nærmest er blevet lidt for gode til at bygge teknologier oven på andre teknologier. Lag på lag på lag... indtil man får en kæmpe høj stabel af alt for ressourcekrævende kode.

Jeg ved godt det er utopisk, men tænk hvis man skrev kode lige så lean & mean på nutidens computere som man gjorde på f.eks. demoscenen i slutningen af 80erne. Alt ville være fantastisk responsivt og hurtigtreagerende.

  • 12
  • 0
Henrik Mikael Kristensen

Det var idéen om at vi skulle køre apps i webbrowsere, der er en håbløst kompliceret måde at køre en GUI engine på.

Havde man baseret sig på at kunne bruge en webbrowser form factor med en stærkt formindsket og optimeret GUI engine i stedet, så kunne man sagtens bygge webbrowser apps, der kørte ved native hastigheder med et meget lille ressourceforbrug.

  • 4
  • 1
Kenneth Rohde

Dette blev fikset i Chrome nogen tid siden, men Electron bruger nok en gammel udgave.

Det har intet med web browsere, CSS eller HTML at goere, men i stedet laa problemet i compositoren som invaliderede en hel tile af gangen i stedet for kun at gentegne omraadet som blev aendret.

Tiles bruges ofte da de sikrer async render opdates (back and front buffer) og fordi de er gode til scrolling og zooming, fx kan kan scalere tile'ene direkte paa GPUen og saa foerst gen-rendere naar man giver slip.

Nu har jeg ogsaa arbejdet paa Qt (native) hvor vi faktisk har haft et lignende problem - Det at animere noget hele tiden er jo bare ikke gratis, saa opdaterer man ikke kun det man skal kan det hurtigt gaa galt :-) - native eller ej.

  • 0
  • 1
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize