[cryo]

The Pico runs at 133 MHz. I don't know how the slint-ui works under the hood but the shown demo (with DMA speedup) could be much more snappy imho. For that the code needs to be aligned to what the SPI protocol of the display offers instead of treating it as a general purpose frame buffer. For example while scrolling not sending the whole area but only the part which becomes visible.

[devbent]

The Microsoft Band managed a fancier UI with only 96mhz of CPU, it did have an FPU though which speeds things up quite a bit.

Getting good throughput requires DMA, and Band also paid the price and dedicated tons of local SRAM for the frame buffer. A local framebuffer that can be read from is needed for antialiased fonts and alpha blending, not to mention things like screen fades!

Band also had real true type fonts, and ran at 30FPS[1] with vsync!

I did a write-up of how at https://meanderingthoughts.hashnode.dev/cooperative-multitas...

[1] the 30fps cap was due to bandwidth to the display controller, uncapped the UI could run internally at around 100fps if it wasn't doing loads of text rendering.

[solarkraft]

Little side note: Props for the regard for UI quality.

> At launch, the Microsoft Band dropped fewer frames than an Apple Watch

> if any module took more than 2ms before it returned, a crash dump was created and the code was investigated and optimized.

If only Microsoft cared even half as much about the UI in its other products. Visual Studio still hangs up the main thread for many seconds.

(side side note: touch input/output latency is a field Microsoft is actually remarkably good at, I'm guessing because they did some research on how much it matters decades ago. if only they had done some research about how glaring UX defects impair the over all usage of a product ...)