GLes acceleration with the framebuffer port

I’ve been working with the framebuffer port for a little while now, its an amazing experience to getting to work with it as using embedded graphics has never been easier and it looks and runs amazing.

I’ve been running it on a 1080x1920 screen and my current system manages to run smoothly but uses about 30-40% CPU usage

in the docs I see there is support for acceleration NXP CPUs but we are mostly working with other ARM based SoCs

is there anyway to get acceleration from the Mali GPU via something like gles presumably ?

thank you

Awesome! ^^

Working with a non-embedded GPU is a little bit different.
With GLES (or other high-level GPU) we can’t mix GPU and software rendering (at least not in a trivial way). Therefore all the draw functions of LVGL should be reimplemented with the given GPU. Theoretically, it’s possible but needs a larger amount of work.

1 Like

Would it help to have function calls to do simple things such as lines or rectangles?

Maybe in future lvgl can make specific calls to render images or complex shapes (lines with width, round squares, gradients, shadows… )

However, it would need some care on implementation to take advantage on GPU use…

I see, Its not the most optimised for what I’m trying to achieve, but for what is allowing just wanted to know if there was any possible way to somehow get a pinch more of performance :slightly_smiling_face:

there is no particular use that is related widget wise, but rather when using screens of very high resolution eg 1080x1920 (which is waay above the expected use case I believe :wink:)

this is just what I’m currently working on, its a simple cluster stat panel for SBC cluster,
nothing too fancy, just a couple of widgets, but its mainly just for pleasing aesthetic and simplicity

its a 1080x1920p screen and manages to maintain optimal performance due the reason that its powered by a very fast single board computer.

thanks and best regards :slightly_smiling_face:

1 Like

I think the GPU drawers can be hidden behind the same API as the current LVGL draw functions (e.g. lv_draw_rect). So the LVGL draw part could be replaced by something else.

However, it just came to my mind that on a more powerful system the drawn objects can be buffered. In comparison, LVGL always draws a button when it’s scrolled, altough the button didn’t really change, only its position. So if the drawn button was buffered as an image, and it was “rebuffered” if its style or size changes only its buffered image needs to be drawn.

There is no such concept now, but we are thinking about making objects “buffereable” to allow rotating, scaling, etc them. The two things have similar roots.

1 Like

Sounds interesting. Please keep us updated and open a topic for it in the My projects category if you wish. :slight_smile:

1 Like

I just remember, there is the well known imGUI library where they have bindings for almost all targets. You can get inspiration and some ideas from it :slight_smile:

Integrating Dear ImGui within your custom engine is a matter of 1) wiring mouse/keyboard/gamepad inputs 2) uploading one texture to your GPU/render engine 3) providing a render function that can bind textures and render textured triangles.

2 Likes