Epic discussion: VS Code Uses 13% CPU When Idle Due to Blinking Cursor Rendering

VS Code Uses 13% CPU When Idle Due to Blinking Cursor Rendering

Discussions: Reddit and Hacker News

Couple of citations:

Assuming 1 million users of VS Code This blinking cursor will waste $3 million per year in electricity costs, and output 32,000 tons of c02 per year.

2150: “Grandpa, why did the ocean’s dry up?”
“well sonny, long ago, Microsoft didn’t optimize their code for a code editor’s cursor and pushed earth’s climate over the edge”

TL;DR:

All this is about Microsoft Visual Code editor that is Electron application — Chromium based.

They blink cursor by this CSS declaration:

@keyframes monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

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

Problems with this solution:

  • In chromium / webkit this animation runs with animation frame rate — each 16ms — 60 FPS.
  • As Chromium (WebKit with Skia backend) uses mostly CPU rasterization than simple task of filling 1px rectangle eats CPU (and so drains batteries). On each frame rate whole window gets updated.

In principle all this can be solved by something simple as:

setTimer(function() { caret.toggleClass("visible") }, 1000);

Web Frameworks: React vs Vue

Practical investigation on effectiveness of Virtual DOM (React) updates versus direct DOM updates (Vue).

Stats of list  update having 100 items.
Stats of list update having 100 items.

Clearly React takes significantly more CPU time for the task of updating 100 items list.

That proves once again that there is no silver bullet in Web Front End design. Each task has its own optimal framework/architecture.
“Ideal framework” should allow to use multiple paradigms – list-of-items view should use virtual list, it could be one-way bound with data [model] and item-details may or may not be data bound – depends on its structure.

What if just start from our old friend jQuery with its system of plugins and/or components/modules architecture of Twitter’s Flight.
Where you can add view routing, data bound lists and other plugins of your choice? Only when and where they are needed …

Is it close to that optimal, flexible and stable architecture web applications we are dreaming of?

Maintainable CSS

I have found Maintainable CSS site exceptionally useful for designing maintainable CSS systems.

Modular and encapsulated: Styles don’t bleed or cascade without your permission.

Any design requirements: Completely flexible to your needs.

No tooling required: But you can use tooling if you want to.

Easy to learn: Read the guides and see.

Any size project: Whatever size project you have, MaintainableCSS will help.

Upgrade in your own time: You can start applying the approach today, bit by bit. You don’t need to upgrade the whole

Russian Roulette game, .JS style.

Disclaimer: the game is quite dangerous and may lead to alcoholism of participants even after first game. Play responsibly!

Idea of the game:

Players, in their turn, name random English word. To this word they add “JS” or “.JS” suffix and go google for it.
If google will give JS library or framework with that name – you won and drink one Vodka shot.

You’ll be surprised… and read disclaimer above.

Studies show that a TODO list is the most complex JavaScript app you can build before a newer, better framework is invented.

Allen Pike: “A JS framework on every table”

::mark(…) feature is comming

Please consider these tasks:

  1. Find all words in text on HTML page and highlight them
  2. Syntax highlighting: parse text of <pre> and mark all keywords by changing their color
  3. Find all misspelled words in <textarea> highlight them specifically.

Currently you can do #1 and #2 by wrapping each text found into <span>s with specific classes – thus to modify DOM structure of the document. Such modification by itself is a) not trivial to implement, b) is highly non-desirable (consider text editor with syntax highlighting) and c) even impossible in case of <textarea> for example.

Ideally we should have some facility that will allow us to a) mark text fragments, b) apply styling to such marked runs through CSS and c) do that without DOM tree modifications.

As a result upcoming Sciter will have:

  1. In CSS, support of ::mark(...name[s]...) pseudo element.
  2. In script runtime, new methods of Selection class:
    • Selection.applyMark(start,end, ... mark names...); – to add marks to the range.
    • Selection.clearMark(start,end, ... mark names...); – to clear marks from the range.

Example, CSS:

div::mark(hilite) { background-color:lime; } 
div::mark(hilite2) { background-color:cyan; }
div::mark(literal,string) { font-style:italic; color: red; }

First rule will tell the engine to set background color on all text runs that are marked by “hilite” to “lime”.

And script code

      var text = $(div).firstNode;
      var start = [bookmark: text, 6, false];
      var end   = [bookmark: text, 11, false];
      Selection.applyMark(start,end,"hilite");

will apply mark “hilite” to the text node from 6th until 11th position and so you will have the following rendering:
marks in text nodes
Note: this will not change DOM structure but rather apply some meta information to characters in the text.

display:none is considered harmful

Quite often in HTML/CSS based UIs we need to hide/show some elements in runtime.

Probably the most widespread (and the worst) solution is to set display:none CSS property programmatically.

That sounds quite easy at the first glance but solves only half of the problem – it hides – removes the element from rendering tree. But what you would do when you need to show element that was previously hidden that way? Setting it to display:block is very wrong. Far not all elements have display:block model by default in HTML.  <img>, <input>, <select>, <textarea>, etc are display:inline-block. <table> and all its children have special display:table**** values. Setting them to display:block will lead you to quite surprising results.

Therefore in order to use display:none in runtime you will need to know original display value of the element. Not quite convenient and maintainable. Imagine that your web designer (probably sitting on other continent) decided to replace some elements horizontally by declaring display: table-cell on them. You will get problems hiding/showing such elements by switching display: none <-> block.

To overcome such a problem jQuery for example implements its hide() method by storing existing display value to special property named "olddisplay". And restores the display from that property when you need to show the element. That approach is far from ideal either for obvious reasons.

Better solution

Better solution is to use attribute "hidden". So instead of setting element.style.display CSS property you will need to add attribute "hidden" to the element when you need to hide it and remove that attribute when you will want to show the element. In order this to work you will need to add single and simple rule to your stylesheet:

[hidden] { display:none !important; }

If some elements need to be hidden by default you will use hidden attribute in your markup, for example as:

<button id="ok-button" hidden>OK</button>

In Sciter you can define some virtual property, e.g. "shown", to all DOM elements (in some common "utilities" module):

/* CSS must have [hidden] { display:none } rule in order this to work */
property Element.shown(v) 
{
  get return this.style#display != "none";
  set this.attributes["hidden"] = v ? undefined : true;
}

and use it as

var someEl = ...

someEl.shown = true; // to show
someEl.shown = false; // to hide

The solution is not free from obvious drawbacks though:

  1. you need that special [hidden] { display:none; } rule to be present in your CSS and
  2. In all cases when you need to hide/show the element you should do it either through that special "shown" property or explicitly by removing "hidden" attribute from the element.

visibility:none

Since Sciter version 3.1.0.15 you can use visibility:none; in CSS to exclude the element from rendering. Exactly in the same way as display:none;. It has exactly the same effect.

As the visibility property is orthogonal to the dsiplay you can safely assign "none" and "visible" property to it without affecting display model of the element.

Therefore, the visibility property in Sciter can accept following values:

  • none – the element is excluded from rendering tree in the same way as display:none, that is Sciter specific;
  • hidden – the element is in rendering tree, takes space but not rendered;
  • collapse – the element is in rendering tree, takes space but its height or width is collapsed to zero. E.g. in flow:horizontal container visibility:collapse child will take space vertically but rendering width will be set to zero. In Sciter this will work for any elements but in standard CSS only for table rows for some unknown to me reason.
  • visible – default value, element is rendered normally.

And here is modified version of the shown scripting property defined above:

property Element.shown(v) 
{
  get return this.isVisible;
  set this.style#visibility = v ? "visible" : "none";
}