Does this offer me much over LVGL?
A typed and tooled (lsp, live-preview, etc) DSL for the UI and Rust/C++20 APIs, compared to C APIs.
Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
11–20 of 29 posts
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#12If you get to the inlined video and think it looks a little sluggish, keep reading - they later implemented DMA to speed it up. Here's the link to this video showing it: https://youtube.com/watch?v=dkBwNocItGs
It's slow even with DMA. The original iPhone was snappier than this.
The original iPhone was far more powerful than this hardware.
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#13The 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.
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.
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#14The 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.
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, a…
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 ...)
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#15Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#16It'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...
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…
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.
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#17Earlier quoted context omitted.
The original iPhone was far more powerful than this hardware.
The original Mac was also snappier.
The original Mac was BW and didn’t do the same level of animation.
Of course a snappy interface is always more important than visual flair, but I imagine this is more a tech demo than anything else.
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#18Forget running "a simple ui toolkit". I have ENTIRE PalmOS 5.2 running on the pico with that a screen. At 47FPS !
Feel free to hit me up for pointers.
Video proof: https://photos.app.goo.gl/zZiLnDNLQs2omBXz5
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#19Forget running "a simple ui toolkit". I have ENTIRE PalmOS 5.2 running on the pico with that a screen. At 47FPS ! Feel free to hit me up for pointers. Video proof: https://photos.app.goo.gl/zZiLnDNLQs2omBXz5
Do you know what kind of ui drawing architecture PalmOS uses? Seems like it's probably more aligned with that type of device.
Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM
#20I’m excited about Slint. It’s great to have a solid Qt alternative for embedded UIs. I doubt I will need to use it on a MCU rather than an embedded Linux processor, but even so, it’s also nice to know that it’s lightweight.