Optimizing performance on microcontrollers

[agg23]

I am attempting to use Slint on what is in effect a very low end microcontroller (running on a FPGA). Up until now I've used Slint to run small demos without much problem, but upon trying to run a moderately more complex project, performance starts breaking down.

My project is ultimately very simple, just say 20 colored boxes and text, with no alpha, and some animations on those boxes. During animations I see flickering as Slint draws the individual layers of certain parts of the UI, which indicates to me that this is likely a performance issue.

What should I be doing to get the absolute most performance out of the framework? I've tried both RepaintBufferType::NewBuffer and RepaintBufferType::ReusedBuffer, but there didn't seem to be much difference. Are there features I could turn off (color blending, other things?) that could result in a decent speed up?

I realize this question might be unusual and you might not care to support such low end usecases, but I thought I would ask and put it on the record.

[agg23]

I discovered that a lot of the slowdown disappeared (but not all) when I removed font rendering entirely. I expected fonts to be baked with the software renderer, so the cost to draw them should be minimal. Even without the text, simply animating the position of <16 colored boxes on screen results in significant slowdown on my (admittedly slow) MCU.

[tronical]

Good to discuss this here. Hopefully we’ll get to the bottom.

One thought crossing my mind here is that if glyph rendering in particular is slow, then perhaps it’s related to the memory access to the framebuffer.

I’ve seen cases where those memory regions were incorrectly configured (not running at max clock speed). I’ve also seen cases where due to concurrent access to the same region by a display controller, it was faster to do line-by-line rendering into a separate buffer that’s faster to access for the CPU (especially for blending operations like when drawing glyphs), and also more cache friendly. And then afterwards transfer the line buffer to the display controller read memory region in one go (ideally via DMA).

Could you describe your memory and display setup a little?

[agg23]

The device in question is the Analogue Pocket, an all in one FPGA platform (screen, memory, FPGA, controls). I am running on my custom SoC built on the LiteX FPGA project - https://github.com/agg23/openfpga-litex. This system is very slow; I recorded a Dhrystone score of 31.3 DMIPS (for comparison, the RPi 2040 is about 10x that at ~300).

Memory is directly shared by the processor and display DMA by pretending like they're integrated hardware (as is common with FPGAs). There is no data caching present in the system (I think the LiteX built in L2 doesn't work correctly, given errors I found in testing), though I don't think that would directly matter to Slint, other than just the general cost of calculating the output pixel. The display directly reads as quickly as possible, filling up a FIFO which is dispensed as pixels are required at the correct cycle of screen output. This has the effect of essentially halting the CPU while the reads are occurring, as the memory is not dual ported.

There are actually two memories on the bus, where the much smaller one is internal to the FPGA and can be accessed in a single cycle at all times. I've considered trying to relocate some memory there, but I think I would have to figure out how to bifurcate Rust's allocator setup, as all of the heap can't fit on this RAM.

---

It may simply be that this setup is too slow to be used in a reasonable manner with Slint (at least with animations), but I would like to learn about any mechanisms I can use to optimize, if any.

[tronical]

This has the effect of essentially halting the CPU while the reads are occurring, as the memory is not dual ported.

Oops.

Is there a way to pause the read-out while doing CPU rendering?

[agg23]

It would be possible, yes. I expect that would have identical performance however (+/- a few cycles) as a pause is the same pause if you pause it right now for say 4 pixels (repeating interwoven CPU and display up to the total number of n pixels), or if you pause for the entirety of n pixels.

[tronical]

Hmm I thought that overdraw would be worse if it’s paused. If say the pixel at (0, 0) is written to say four times (due to overlapping opaque rectangles) and the read and written again due to a glyph blending, then I’d imagine that its overall faster to do that uninterrupted / without pause.

Or would the screen turn blank if the read-out is paused?

[agg23]

Display read never is preempted; it only stops itself because it burst read n bytes and filled up the FIFO, so there's never a problem with the display not having enough data. This means while Slint is writing to a pixel four times, it could get interrupted in that process several times, but like I said I don't think there's a difference whether it's interrupted there, or interrupted at another spot later when the frame is ready.

There is no L2 data cache, so the display burst read can't clobber the CPU's cache or anything like that, so the CPU should take the exact same amount of time, though potentially cut up into fragments.

I do worry that the n writes are the problem though, because I don't think the memory latency is very good in this setup.