> They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications

In embedded SoCs the memory bandwidth is often shared between the CPU and the GPU. There is not a separate pool of memory and bandwidth for the GPU.

> The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc).

That’s not what the parent comment is talking about. To get the data into the framebuffer you need to write it first. You also need to read the source images. For blending two images and writing the output, the floor is 3X the total image size every single frame. (Two reads, one write). There are tricks that can be played with frame buffers and scan out blending, but you get the idea.

> And train stop displays certainly don't need 60 fps.

We’re talking about the product in the link, which is trying to blend seamlessly between two images at 60fps.

> The main constraint for high-resolution displays is memory, not CPU clock speed.

I don’t think you understood the problem space.

If you’re doing software blending of 10MB image buffers at 60fps, the CPU can be easily be a bottleneck. You have to ensure the CPU can do enough load operations, math on the loaded data, and store operations to get it done in 16.7ms. Ideally you have a GPU, but if you don’t then you need to pay close attention to optimizations and special instructions to get it done within the frame budget and also allow some cycles for all of the other work the app has to do.

> Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.

The 1920x1920 size came from the article. Parent commenter wasn’t making up odd sizes, they were responding to the article.