Hacker News Reader

Comment by ilyt | Hacker News Reader

It's funny to compare "modern" with microcomputers of the old. Original Amiga 500 ran with 512kB RAM, with OS requiring only 256kB (as in "you could run something other than just OS on that").

Meanwhile we have this laggy mess...

View on HN

The Amiga had a dedicated video chip (and it output vga signals which are fairly cheap).

This is a slow SPI bus with the cpu needing to push W x H x BPP pixels and with a 320x240 16bpp that comes out to 9 million bytes/sec for 60fps or 4.5 million for 30 fps. Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel, that comes out to a best case ~80 fps @ 100MHz with 100% cpu utilization (i.e you could do nothing else on that cpu, not even serve interrupts). Another core wont help much because it shares the memory bus, and fill rate is the bottleneck here.

There's a good reason why we have dedicated chips for pushing framebuffer -> lcd physical pixels even back in the 80s.

Yep. The really neat part of their port is their weird DMA/scan program architecture. It works for them, and is a decent way to work around what (I would assume) is a toolkit that needs a frame buffer instead of computing the line on the fly from a draw list.

> with the cpu needing to push W x H x BPP pixels

Only if it needs to update the entire screen for every frame, which it probably doesn't.

> Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel

DMA can shovel data from RAM straight into the SPI peripheral with no CPU involvement beyond the initial setup (which is simple).

But it doesn't need to push every frame every second, the whole screen not always changes

> Another core wont help much because it shares the memory bus, and fill rate is the bottleneck here.

Depends on CPU, some (RP2040 for example) have segmented memory which means you can just have one core working on the graphics, and dedicate segment to DMA

Slint already supports rendering just the dirty regions of the screen. SPI is a major performance handicap though — they could use PIO on the RP2040 to implement an 8 or 16 bit parallel bus (and then they’d need a display with support for parallel IO), and that would help a ton.

Here’s Slint running on my own backend for the Teensy MicroMod (has an NXP i.MX RT1062 processor) using DMA and an 8-bit parallel bus using FlexIO:

https://twitter.com/charlesstrahan/status/163002622435647488...

I’d say that’s fairly smooth.

Reply on news.ycombinator.com