Canvas performance on STM32-S3?

[dgarlans]

I'm working on a project using one of the Makerlabs 4" lcd's with the ESP32-S3-WROOM-1U-N16R8 .

I need to be able to display bitmaps and things similar to an animated gif at a reasonable frame rate (at least 15fps ideally).

I would like to be able to render those items to a canvas and then apply some basic post-processing to that canvas.

I've looked at some of the example videos of that board though, and everything looks really choppy - it shows lvgs entities rendering at like 6fps in some cases, and it shows bitmaps taking a visible half-second or so to refresh, and so on.

Is the chip/code actually capable of updating the screen in such a way that the refresh happens instantly, rather than seeing it scanning across the display?

[moononournation]

You may try ImageViewer examples first, it have Animated-GIF and MJPEG example. 15fps is a very high requirement for a 480x480 display, I think it can reach 10 fps.

[moononournation]

This is the common Phenomenon for ESP32-S3 + RGB.

[dgarlans]

So would spi be better? I've seen videos of screens running in spi mode that were rock solid!

[moononournation]

depends on what resolution you want

[dgarlans]

I've done a lot more research and looked at datasheets and schematics, and it looks like the secret is to time the screen updates with the vsync pin, which makes sense, and that pin is available to the microcontroller as well.

Is there any provision in the code right now for deferring the flush until the vsync pulse is clear? would auto_flush be part of this? (i'm digging through the code now to find more details)

[dgarlans]

i've got the boards on-hand and i can see at least basic graphics can update extremely quickly, however i'm still at a loss at how to handle the vsync. it seems that the vsync pin is specified in the constructor, however it looks like it never goes anywhere, and if i try to read that pin i don't seem to get anything either.

[dgarlans]

The size and aspect ratio was most important for me, and the 400x400 screen was basically the only option. I really would have thought that with the parallel data of the rgb+spi that transfer rate wouldn't be as big an issue, unless the problem is the controller itself not being able to double buffer or cache.

…

On Mon, Sep 18, 2023, 8:12 PM moononournation ***@***.***> wrote: depends on what resolution you want — Reply to this email directly, view it on GitHub <#349 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJPNAJ7LXQ3ELUOQNENEOLX3DPPTANCNFSM6AAAAAA45IMY5E> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>