The assertion that gpu is required for good text rendering caught me off guard. I can't claim it is wrong, but it does feel like it should be wrong.
Resolution could also matter, but we did have higher resolution displays back in the day, as well. Feels like 2d acceleration somehow regressed.
Once upon a time (a decade ago) it was OK for apps to directly draw to the front window, compositing wasn't a super established thing. This saves on precious memory bandwidth, which CPUs didn't really get all that much more of over the last decade.
However now that GPU composition has to happen, GPUs actually don't super like the linear formats that CPUs write to. They want swizzled textures, and they keep those formats private. And on not-heterogeneous memory systems, the buffer the CPU writes into needs to be sent over to the GPU as well.
Meanwhile screen resolutions & pixel counts skyrocket, as did UI visual & animation expectations. Being responsive is a lot easier than being fluid. Especially if you're trying to be fluid on a high-resolution and/or high-refresh rate display.
And this is all while ignoring things like Apple's "high DPI" handling, which is to just say fuck it and downscale instead. Which means you're pushing resolutions far higher than the display's actual resolution quite commonly.
Even sending the buffer to the gpu for compositing makes sense as a problem, but still feels that should be faster than you would care about in a text editor.
I'm also on a mac that, if I do something that is "gpu accelerated", I'm likely to get a frozen session. Such that most applications don't seem to need gpu help. Are they just using different parts of it?
A good intro to layout transitions is: https://www.gamasutra.com/blogs/EgorYusov/20181211/332596/Ta...
The number of copies required to get a pixel from CPU space into photons today is ridiculous. It used to be you'd just write into a memory-mapped buffer, and your graphics card would scan out directly from that where it would get to the electron beam modulator in microseconds.
Such that I agree it would be better to do dirty tracking and sending just a small update to the screen. But the tricks to do that should be a lot easier than they used to be.
The gpu thing in my Mac is amusing just because if I run intellij, it will cause my machine to crash. If I run emacs? Not so much. Even if I am stressing the machine with several compiles or some silly pandas data frames. If I enable gpu accelerations in my browser? Expect instability. My video chat program just boasted that they use gpu for video. And for the past two weeks, it is common for the entire video system of my machine to hang during a video chat... Literally get a crash screen.
Not really, no. Over the last 15 years CPU memory bandwidth has increased around ~10x. Meanwhile monitor resolutions have also increased around ~10x. Meaning per-pixel CPU bandwidth has been flat over the years or even regressing a little bit. Laptops have become more common yet they also lag on memory speeds, or sometimes are even just single channel. Yet they also tend to have the highest resolution displays, not a great mix if you're trying to make CPU rendering still be viable.
As for your Mac issues I think you just have a broken computer. Software shouldn't be designed with the expectation that it'll be used on broken systems, that's not a realistic design constraint.
Linear is just your normal buffer where you index into a pixel at '(y * stride) + x', where stride is probably just the width * bytes per pixel.
But this isn't how GPUs store texture data. They swizzle it so that locality can be maintained well enough regardless of how the texture is rotated. httsp://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-swizzling/ is a decent introduction. https://en.wikipedia.org/wiki/Z-order_curve has more of the general side of things.
There's then also framebuffer compression in addition to all this.
For complex reasons, that's all been changing. For example, Metal on macOS doesn't even have a way to specify partial screen updates. Those optimizations are still valid, though, and in my ideal world we have both good support for partial invalidation and fast GPU rendering. Among other things, that would be really good for power usage. But to get there requires some attention to detail that seems to be mostly gone from the desktop UI space.
Define Hella fast.
If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff.
The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to resize the screen and scroll, resize text, with great fonts, without any delay or sluggishness.
Xi delivered in some of those things, and druid delivers on some of the others.
But essentially, there is no system today where you press a key and that key appears on your screen in less than 8ms. Xi achieves ~16ms on the right platforms - not the fastest but much faster than most text editors.
The idea behind Xi was to preserve that as the editor got more features, like syntax highlightning, and it did.
I get that rendering a full display from scratch could be slow. But updating a single key press should not be. Scrolling? Sure. I guess. But even that feels like we over complicated something in the process.
I note that I do not disbelieve you. My asserting that it is ridiculous is that it sounds ridiculous.
> I have a multi core machine running at speeds well above my comprehension and you are saying they can't render simple 2d primitives at speed? That just blows my mind. What are they spending the time on?
Moving memory from RAM to the CPU, doing stuff in the CPU, moving the results back to RAM, moving those results from RAM to the GPU, etc.
The CPU is fast, but moving memory around is not, so the CPU and the GPU just end up doing nothing most of the time, waiting for memory most of the time.
---
Raph's blog (linked at the top), has a bunch of articles about rendering latency. But just google about typing latency, there are a couple of projects and tools that measure the time between a physical keystroke is pressed, and the letter being rendered on the screen (end-to-end). Beyond the memory copies, what usually happens is also: an interrupt is triggered on the CPU, the kernel might take some time to context switch to catch it, context switching requires saving all registers, and restoring them, and registers have exploded in size over time (e.g. with AVX-512 you need to save quite a bit of memory), then the kernel notifies the application, which needs to do something with the key press, like scheduling a render into a frame buffer, etc.
So there are just quite a bit of bounces from here to there in the system, most of which deal with memory latencies, and memory latencies is the part of the system that hasn't been getting much faster over the last 30 years.
How does one measure this? Say for the text editor I'm using (Emacs) or for Chrome/Google Docs?
// Mac only. Valid values are true, false, and "auto". Auto will enable
// the setting when running on a screen 2560 pixels or wider (i.e., a
// Retina display). When this setting is enabled, OpenGL is used to
// accelerate drawing. Sublime Text must be restarted for changes to take
// effect.
"gpu_window_buffer": "auto",