Hacker News Reader

Comment by pmalynin | Hacker News Reader

https://docs.lvgl.io/master/details/integration/adding-lvgl-...

Ok, so I take from this that it uses pixel buffers directly, and has no opengl support (which would allow GPU acceleration).

This appears to be for low-power embedded devices, not anything that would have a GPU

Renderer[1] Draw Units[2] include various GPUs, SDL (and thus OpenGL; looks like SDL2), and a direct OpenGL ES seems in progress[3].

[1] https://docs.lvgl.io/master/details/integration/renderers/in... [2] https://docs.lvgl.io/master/details/main-modules/draw.html#d... [3] https://github.com/lvgl/lvgl/issues/6763#issuecomment-262319...

This is for screens usually controlled by microcontrollers, nothing running close to an operating system like Linux and rarely coming with a GPU.

See for examples ILI9341 or SSD1306 displays[1] or integrated boards with (often) an ESP32 microcontroller and a display attached[2].

[1] displays: https://www.google.com/search?q=SSD1306+OR+ILI9341+display&u...

[2] integrated: https://www.aliexpress.us/w/wholesale-ESP32-LVGL.html?spm=a2...

You don't really need a GPU when your screen is small and you might only be updating it no faster than ~1 fps and could tolerate ~100ms latency in response to an event. And keep in mind most DOS games were software-rendered on CPUs much less powerful than your modern higher-end microcontroller (e.g. rpi pico, stm32, esp32, etc).

Instead of a full GPU, some microcontrollers may have a special "Blitter" engine...for instance NXP has a "Pixel Pipeline-Processor" (PXP) engine which is just-enough hardware for scaling, rotating, alpha-blending, and copying pixels, and it is for instance possible to configure lvgl to use the PXP to handle such grunt work while leaving the rest of lvgl rendering to software.

DOS games on weaker chips still weren't 1fps 100ms. Even without blitters, which commonly appeared only around windows 95 era afair, they ran pretty smoothly for the hardware they had. Any modern cheapest weakest chip will run timespace-warping circles around 8086, not to mention "prev gen" chips.

Exactly my point (I couldn't tell if you were agreeing or disagreeing). I pulled the "1fps 100ms" number as target that a user might tolerate for a typical embedded display. And since as I said modern higher-end microcontrollers are much more powerful that dos-era CPUs (which could run games much faster), the unspoken conclusion I was trying to convince the previous commenter of is that a GPU (beyond maybe a specialized blitter-like pipeline) is unnecessary for the demands of typical embedded application displays. I was also going to give the example that the GUIs of early versions of Windows were software-rendered too.

Out of curiosity I'm looking at the most recent demo video LVGL posted, which benchmarked an ESP32-S2, and it's getting between 50ms-100ms for various tests like rotating multiple bitmaps and such.[1] So seems like the "100ms" number I pulled was quite apprirate for what LVGL can do on on a popular modern microcontroller.

(Also note for any readers: when I typed "1fps", that wasn't a typo for "10 fps". An embedded application would be wanting to do something else for that ~90% remaining CPU time each second that is not spent software-rendering the GUI.)

[1] https://www.youtube.com/watch?v=uHdSQY_k2Mg

Reply on news.ycombinator.com