We’re developing on a Quad-core Cortex-A35 and Mali-G31 GPU platform using LVGL v9.3. However, the resolution reaches 720p, sw rendering frame rate is low. I’d like to know how much OpenGLES rendering performance improves compared to CPU rendering by enabling LV_USE_DRAW_OPENGLES in LVGL.
From the code, it appears that OpenGLES only handles non-rounded corners and transition colors in LV_DRAW_TASK_TYPE_FILL, as well as LV_DRAW_TASK_TYPE_LAYER. Overall, it handles relatively few rendering steps. What are the future plans for OpenGLES rendering?
Hello, I’ve been doing a lot of work recently on everything about OpenGLES rendering in LVGL, and this will be reflected in the latest release soon. We have considerably improved performance. Here’s what you can expect out of LVGL running OpenGLES with the DRM + EGL output driver.
My testing was done on a Raspberry Pi 3B running a 800x480 HDMI display. I modified my LVGL configuration to max out at 500fps or whatever the GPU can deliver, whichever is less.
Using the DRM driver with EGL, and LV_USE_DRAW_OPENGLES = 1
Average FPS: 389
and using the same driver but with LV_USE_DRAW_OPENGLES = 0
Average FPS: 309
If you were to use the default LVGL 30 fps timing settings, all benchmark tests will run at 30 fps solidly using between 4% and 6% CPU.
Raising the frame rate to 60 does not significantly change those CPU usage numbers, and it will also run at a solid 60fps.
Your performance figures will likely run a bit lower since 720p is a larger display to render, but they will be comparable and well over a 100 for both, probably closer to 200fps.
So you can expect drastically improved performance out of the OpenGLES rendering path in the latest version of LVGL, but make sure you’re using the new DRM + EGL fullscreen driver, as that’s the one I’ve optimized so far.
Before updating, i would suggest waiting another few days, maybe a week, there are a few finishing touches being applied to the code now to make it easier to drop in with existing builds.
Here is a sample I captured directly from the HDMI output of the RPi3B using a capture card several days ago. This specific test was done at 720x480 and the code was optimized a little bit more after this clip, too (notably, widgets demo speed improved further, it’s still having some slight issues in this clip)
This video link is hosted on streamable and will expire in 2 days:
[Watch 2025-09-23_08-41-16 | Streamable](https://Benchmark tests at 720x480 on RPi3B with DRM+EGL driver)
Hi, is the OpenGL ES rendering optimization complete? Can I verify it by using the master branch of GitHub - lvgl/lv_port_linux: LVGL configured to work with a standard Linux framebuffer? Only LV_USE_LINUX_DRM/LV_LINUX_DRM_USE_EGL/LV_USE_OPENGLES/LV_OPENGLES_API_EGL/LV_USE_DRAW_OPENGLES is configured. Doesn’t it require a windowing environment like GLFW/WAYLAND?
It will work with or without Wayland, there is an option for OpenGLES direct to DRM with EGL we’re finishing up now.
Hi @senlinding
I just updated lv_port_linux to be able to work with DRM + EGL. Simply enable these settings in lv_conf.h
LV_USE_OPENGLES 1
LV_USE_LINUX_DRM 1
LV_LINUX_DRM_USE_EGL 1
You might also try enabling the opengl draw unit but depending on the UI it might slow things down for you
LV_USE_DRAW_OPENGLES 1
