Render performance on ESP32 S3

[egast]

Hi,

I am experimenting with running Slint on an ESP32 S3 (no_std). I have followed the instructions in the documentation and I have copied the printerdemo_mcu .slint files so I can test how well the printerdemo runs.
I am able to run the printer demo, but I am a bit disappointed about the performance. The frame rate is low and when I benchmark the render function, a full render (368x448) takes about 210 ms. For smaller (dirty) regions it is faster but still pretty slow, for example drawing a 34x348 (dirty) region takes about 74 ms. I am wondering if this kind of performance is normal and is there a wait to improve the performance?

I am using Slint 1.92 with software rendering (ReusedBuffer) and I let slint render to a Rgb565Pixel frame buffer of 368x448 pixels ( renderer.render(&mut buffer, LCD_WIDTH_RES as usize)).

[aurindam]

There is definitely room for improvement. Here are some key areas to focus on:

• Optimize overdrawing to reduce unnecessary rendering.
• Improve the main rendering loop—there’s likely significant room for gains.
• Utilize the second core for better performance.

We have also identified other issues that need to be addressed for the software renderer: https://github.com/slint-ui/slint/issues?q=is%3Aissue%20state%3Aopen%20software%20renderer%20label%3Aa%3Arenderer-software

The main challenge that we face is balancing between customer-requested features (that gives us much needed cash) and general performance improvements. So far, customers using Slint on ESP32 have GUI that generally feature minimal animations and full-page transitions (so no scrolling) for example https://youtu.be/xPW3XAIU3vQ?feature=shared&t=41

If this topic needs to be addressed urgently, then please reach out to me https://cal.slint.dev/aurindam and we will try to see if/how we can fit this in our roadmap.

In the meanwhile, I will convert this into an issue - #7631

[egast]

@aurindam Thank you for your response. I understand that this might not have a high priority. Could you maybe point me to code that can probably be optimized (for example in the rendering loop), so I can have a try myself?

[ogoffart]

If you are not doing it already, you can use the line by line renderer.
this can perform much better because of caching.
Ideally using a DMA transfer to send the pixel from one line while rendering the next line in another buffer in parallel.

Otherwise, I believe the critical code (inner loop) for the software renderer is in https://github.com/slint-ui/slint/blob/master/internal/core/software_renderer/draw_functions.rs and there might be way to optimize these.

I've also got some work in progress to reduce overdraw in commits such as 099f9fe, or opaque region detection in the olivier/esp32-p4-hacks-opacity-wip branch. (this is a bit outdated and was just experimentation that we should, at some point, polish and merge. There is probably some merge conflicts by now though)

[egast]

I had a look the the draw_function.rs code and I think it might be very hard to optimize the performance so that it performs how I would like it to perform. I have identified the the draw_rounded_rectangle_line function has a big impact on the performance, but it is already pretty well optimized (is far as I can tell). I think a way to improve the performance quite a bit is to reuse calculated values more, but this is not possible, because these functions draw per line and values have to be recomputed on every line draw.

BTW I do really like Slint. It is very easy to use and it even runs on MCU's!

[ogoffart]

I think a way to improve the performance quite a bit is to reuse calculated values more, but this is not possible, because these functions draw per line and values have to be recomputed on every line draw.

Perhaps we should pre-compute some of the values and store them in the RoundedRectangle
I'm sure it is possible to improve. Like we do many sqrt, perhaps that's the slow part and there could maybe be a better way, or just compute one sqrt for the first bound, but only keeping the square value of the second bound and compare against the next value (and take the adventage that (X+1)² = x²+2*x+1
If the blending is expensive, maybe there is a way to optimize the blending. (eg, use "SIMD" with 32 or 64bit integer to operate on several colors at once.
perhaps also simplify if border = 0.