Blinking Cursor Turns 54 | Hacker News Reader

Blinking Cursor Turns 54

hackaday.com

81 pointselvis7046 comments

Interestingly enough, disabling cursor blinks on the intel 950 iGPUs resulted in increased powersaving: https://lwn.net/Articles/317922/ and http://tuxdiary.com/2015/09/29/save-battery-intel-linux/

A few years later, I checked that with powertop when I was using my thinkpad in uni and it was true and measurable!

I'm not sure if it's still the case, but it's funny how UI features can tax the power budget in unsuspected ways.

“A blinking cursor can have a significant effect on battery life, as such we decided to change the default to non-blinking.”

Sublime Text 4 Update FAQ, May 2021

https://forum.sublimetext.com/t/sublime-text-4-update-faq/58...

Haha, that's probably an electron app. Or they use a really buggy UI framework. Otherwise, I wouldn't know why updating a 4x8 pixel block would cause a significant amount of power usage. Especially if a 286 could do it no problemo.

Sublime is a native C++ app. It uses a minimal custom framework built on top of I think skia which actually mediates the drawing on hardware devices (or the CPU). As described by the articles the power usage comes from causing the hardware to repeatedly exit a low wattage deep idle state to update the UI not to do with the amount of work required to render the update.

This is actually more noticeable for efficient apps than inefficient/bloated apps as the latter don't get as many chances to enter deep idle states in the first place.

> repeatedly exit a low wattage deep idle state to update the UI

There's a considerable difference in doing that once a second and dozens (hundreds? thousands? depending on how it was implemented) times a second, which I would assume what the previous default ("smooth") setting meant.

No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU.

There are ways around it, but it requires direct interaction with the compositor, which while supported by the APIs, it's more complicated.

> No, it's caused by modern desktops being composited. Changing a single pixel in a window requires a full surface flush of that window to the GPU.

So evolution. Does this mean that a laptop with lower screen resolution has better battety life ? It explaines why Win 10 is so crappy with screen and cursor updates.

A laptop with a lower screen resolution has entered battery life but that has more to do with the fact you need brighter backlights to get the same brightness from a more dense panel. Pretty common to see 1080p versions of laptops that also have 4K options have significantly more battery life.

Exactly why I hate how laptop manufacturers shove 4K displays into laptops just because it sounds impressive. 4K is more dense than any laptop needs (maaayyyybe 17" ones benefit, but at that size they're optimized for performance at the expense of battery life anyway). Would be great if more laptops had resolutions between 1080p and 4K so things can look sharp without being too hard on battery life.

It’s a native c++ app

https://news.ycombinator.com/item?id=2822114

A 286 didn't do anything to flash a cursor in e.g. VGA text mode - the graphics adapter did using a counter controlled by the refresh rate.

The tone of your reply is inappropriate. Any apps that cause a change in the content displayed risk causing wakeups on the GPU.

It's true whether it's a terminal emulator, a browser or an office suite.

GPU power saving loves static content (OLED screens don't, but that's another story)

Combining the replies from zamadatix, jablan, 323, and jpe90, it seems to me like the UI framework is the culprit and could be (should be?) improved.

If using the API's correctly, the compositor can be limited to only updating a small part of the screen. If really only switching the cursor between on and off, that'll happen roughly once per second. And lastly, the whole thing can be skipped completely if the cursor happens to be invisible, for example if the editor is minimized or (partially or fully) obscured by other windows.

One of sublime's selling points is that it's not an electron app.

And moving your mouse around made Windows 95 faster!

https://www.extremetech.com/computing/294907-why-moving-the-...

You can still observe a related effect to this in Windows 10. Open up any large(ish) file in NotePad++ or most any other editor and place the cursor in the text and drag to the bottom of the screen so it starts scrolling. If you hold the mouse still at that point it will scroll through a couple dozen every half second or so, but if you wag the mouse side to side it will scroll through hundreds at a time in the same span.

I always assume that it's because the apps simply scroll on both timer events and mouse move events. Wiggle the mouse to raise a bunch of mouse move events and you get faster scrolling.

every time I use this trick, I think of how running diagonally in some games is faster than running in one direction...

I think that's just because those games are written poorly and don't account for the differences in moving diagonally. If you are moving on a grid, moving forward one tile moves you the length of a tile. Moving diagonally one tile moves you sqrt(2) ~1.4 tile lengths.

More often it is because both inputs apply some speed. Like in doom.

https://doom.fandom.com/wiki/Straferunning

always normalize your input vectors!

Yeah people always look at me like I'm crazy when I do that, but it really does work

And moving your mouse around made Windows 95 faster!

Still the case with macOS in Finder. Even on Big Sur running on an M1. I dealt with this over the weekend.

Remember when Visual Studio Code consumed 13% of one CPU core to blink the cursor?

Any idea what the processor cost of hitting "insert" and having the big rectangular cursor was?

The shape of the cursor isn't the problem - the fact that the shape regularly changes when blinking is.

The hackaday article doesn't add much. The actual article is: https://www.inverse.com/innovation/blinking-cursor-history

... and the history professor from the University of Reading has the history wrong. As I wrote at https://retrocomputing.stackexchange.com/a/11032/1932 , whilst Charles S. Kiesling's patent was filed in August 1967, the blinking cursor had actually been around since at least the Datanet-760 from General Electric coming out in 1965. The patent filing date is not its birth date. It has not turned 54 this year.

I've been using Emacs since 1996. One of the many reasons I like it is the default non-blinking full block cursor. It brings a certain calmness to the editing process. No stress or distraction. It feels so clean.

It's interesting how very subtle design decisions like these matter so much.

My perception is the opposite: it's stressful to see a non-blinking block cursor, because that's what emacs looks like when it locks up. Frozen cursors are the very first visible indication. Switching to a "calm" cursor, to me, would feel a bit like an Apple user setting their default mouse cursor to a pinwheel of doom [0].

(Background: emacs is a single-threaded lisp program, and "blink the cursor" is just another lisp function [1] running on an event timer. (At least that's the case in GTK emacs). So if any lisp function hard-crashes, the cursor will immediately crash too).

[0] https://en.wikipedia.org/wiki/Spinning_pinwheel

[1] https://github.com/emacs-mirror/emacs/blob/emacs-28/lisp/fra...

I prefer a blinking cursor, otherwise I often find it hard to find the cursor on the screen.

Also prefer block cursor to underline cursor for the same reason.

On Windows Terminal and others, I think you can use a non standard color (example: red, pink...) which should help you easily locate it.

Emacs has a lot of cool little touches to the way it blinks the cursor.

blink-cursor-delay (defaults to 0.5 seconds): Keeps the cursor visible and not blinking when you're rapidly navigating around or typing. Most other apps seem to do this sort of thing too, but it's an easy detail to overlook.

blink-cursor-blinks (defaults to 10): Blinks the cursor a certain number of times and then stops blinking.

One way I do customize it is to set blink-cursor-alist to '((t . hollow)). When the cursor blinks it alternates between a full block and the outline of a block so that it never disappears completely.

Is that the default? The cursor in my Emacs blinks and I don't believe I told it to.

Edit: M-x blink-cursor-mode FTW - thanks!

Uh, please clarify? :)

I do believe it is the default. Hard to know what's default when you've been carrying over your .emacs for two decades.

Every single fresh install on random throwaway installs I've done has defaulted to a single non-blinking block cursor though.

It's easy -- just run "emacs -q" to bypass all your local config. Default in GUI is a blinking cursor. (Default in terminal is the terminal's own blink default.)

> Default in GUI is a blinking cursor. (Default in terminal is the terminal's own blink default.)

Ah, that probably explains my confusion. Sorry about spreading it.

Emacs does blink by default. On the other hand, it is the only piece of software I know with `blink-cursor-blinks` - which is I think 10 by default, I've reduced it to 3 - so the cursor blinks only a couple times and then stops.

Blinking can be disabled in RStudio, too, though it's not the default. I know this because RStudio doesn't respect my XFCE settings, where blinking can also be disabled, or the blinking-rate set (almost) OS-wide.

As I wrote at https://retrocomputing.stackexchange.com/a/11032/1932 Charles A. Kiesling is the best that my research turns up, but xe might not have been the first.

More importantly, however, and also as I wrote there, the blinking cursor has existed since at least 1965, and has not just turned 54 this year.

Good old blinking cursors, one of those computing things that are almost invisible until they're missing.

The MAME emulation of the Tandy 2000 is reasonably complete. I get the feeling that it was barely worked on until Windows 1.0 for the 2000 turned up, then there was a flurry of activity to get that working. The reason is because while the system is mostly emulated, one critical component is not: the display board's support for a hardware blinking cursor. As a result, if you're navigating a word processing document in, say, WordStar, you're largely doing so blind. Only programs with a soft cursor (like GW-BASIC in graphic mode) work like they should.

If you also dislike this: https://jurta.org/en/prog/noblink

The popularity is strange to me. (In this comment thread: "good old blinking cursor", blinking as default, and the reason to change the default not being that anyone hates it but just to save power.)

It's like it's jumping up and down yelling "look at me, look at me!", tirelessly. Who can think with that going on? I guess this is not a neurotypical reaction.

I miss nbtsr (no blink terminate and stay resident). Wish there was something for modern OS's.

Thankfully, you can turn off cursor blinking on Windows (by turning the blink rate down to zero).

I love the blinking cursor; the only time i have reason to revile it's existence was with the late Terry Davis' Temple OS.

Though with a quick Kernel patch you can slow it down. I just know that if the cursor blinks faster than what we are used to, I find it causes anxiety and is greatly distracting.

Reply on news.ycombinator.com