Comment by paulirish | Hacker News Reader

Comment by paulirish | Hacker News Reader

Parent Full thread

Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own.

In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a `step` timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587.

So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work. I think the added visibility on this topic will likely escalate the priority of the fix. :)

* Simple text editors, and basic ones built on [contenteditable] can, but those rarely scale to the feature set most want.

(I work on the Chrome team, though not on the rendering engine)

"So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval"

Only? It shouldn't be necessary to layout the entire window to redraw a cursor.

Also, if it did update every 500ms:

- it still would use about half a percent of CPU. On a machine whose CPU easily is >200 times as fast as those powering the first GUIs (and those _could_ blink the caret at less than 100% CPU) and that has a powerful GPU, that's bad (yes, those old-hat systems had far fewer pixels to update, but that's not a good excuse)

- implementing smoother blinking (rendering various shades of gray in-between) would mean going back to 13% CPU.

I would try and hack this by layering an empty textfield on top of the content, just to get a blinking caret. Or is it too hard to make that the right size and position it correctly?

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own.

Is there any reason that Electron couldn't provide an API that would expose the system caret in an OS-agnostic manner? Windows, for example, has an API[0] that can arbitrarily show the caret at a given point in the window. Sounds like something that would be useful to many apps and not get in the way for those that don't need it.

[0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

Probably not easily. Remember this is what java AWT did and it was a complete mess. Write once debug everywhere.

My favorite issues was that on one OS (windows I think) a panel would only be visible if pixel 0,0 was on the screen and nothing was on top of it. The panel could be 99% visible but not be shown at all if the upper left corner was under another panel.

Why are you even painting at all instead of layerizing it?

(This is a perfect example of what I've been increasingly convinced of lately: that the whole "paint"/"compositing" distinction hurts the Web…)

>> text editors built on the web stack cannot rely on the OS text caret

Can you explain in simple terms why this is the case? Why on earth not?

Because you can't just ask the OS to "please paint text caret here thankyou", and browsers do not expose a powerful enough native text editing control. So you end up reimplementing one in JS/HTML/CSS, including the caret.

The WinAPI function SetCaretPos seems to do that: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

Well, because, in order to satisfy the most finicky of its users (myself included), VS Code offers no less than 6 styles for its cursor ('block', 'block-outline', 'line', 'line-thin', 'underline' and 'underline-thin') and 5 animations ('blink', 'smooth', 'phase', 'expand' and 'solid'). Also, in a future release the themes will be allowed to change the color of the cursor to any of the 16,581,375 colors in the RGB spectrum.

Does that answer your question? :)

>http://crbug.com/361587

Reported almost 3 years ago and still not fixed...

Reply on news.ycombinator.com