Hacker News Reader

Comment by cookguyruffles | Hacker News Reader

Is there any indication of the energy impact using a GL context to render plain old text? These concepts seem incompatible in the context of a laptop, and who needs GL here when the bottleneck is biological. One of my favourite working modes is shutting down everything and just hacking away in vim, partly for distraction management but primarily because of battery.

View on HN

There is at lease one open issue¹ with the clipboard crate that causes a high amount of wakeups (under Wayland at least). Whatmore, the wakeups scale with the number of terminals open. The project is ruthless about performance[latency] regressions, but not so much about performance[energy] overhead.

[¹https://github.com/alacritty/alacritty/issues/3108]

They seem to care more about throughput than latency.

Yes, which seems very very weird to me. When it launched they immediately marketed it as super fast, but just typing into it had noticeable latency. Throughput is great if a command is producing massive amounts of output, but it's not like you're going to read at that speed. I can usually pipe into less instead.

I hope latency has improved to be much better. Haven't tried it in a few years.

Why would GL rendering be any less efficient ? You don't have to rerender the entire screen in GL or render at MAX FPS if nothing changed.

I'd be incredibly surprised if mobile power management did not account for the difference between "blitting array of 2D pixels" and "running massively parallel shader". Even if not done for energy conservation, it might be for TDP profile.

Separately, it's long been a thing on Nvidia Optimus laptops where the most inexplicable thing could cause the iGPU to be swapped out for the power-hungry discrete GPU. A GL-powered terminal definitely seems like it could be in that territory.

In short, many reasons it could be less efficient, hence the question, is there any evidence that it /is/ less efficient?

These days a lot (most ?) of rendering toolkits are GPU accelerated, including things like your browser - you'd likely hit those issues with other apps as well then.

You could hit drivers bugs for sure, but that means in your particular config GL will be worse so you need to test, doubt this translates to a general scenario.

I think a lot of people assume because your default GL setup is to use immediate mode to re-render everything at refresh rate that's the only way to do rendering and that's why GL apps get the reputation for being power hungry.

It may or may not be - it certainly should be tested.

Well it can't be known for certain without performing benchmarks to test it, but I would presume a hardware-accelerated renderer is far more efficient than a software-based one.

Everything is a GL context under wayland isn't it?

It's technically possible to create a wayland compositor without GL/GLES/Vulkan, but only SHM clients will work, unless you go with mixed approach which wouldn't be zero-copy. (Or of course you could also use llvmpipe or something to do software emulation of GL, but that will be very slow and ineffective). I'm not aware of any such wayland compositor however.

Reply on news.ycombinator.com