patacongo commented on PR #12733:
URL: https://github.com/apache/nuttx/pull/12733#issuecomment-2239550294
> Since LVGL simply renders to a buffer that is setup in user-land, can an
app not simply use LVGL to render to an NX RAM-backed window without any change
to the NX/NuttX ecosystem?
The RAM backed windows are an option and it sounds like you don't need the
option since the buffering will occur in user space.
> Very interested to discuss this further - when I asked a question that was
100% related to this issus @gregory-nutt essentially said the same: LVGL on
multiple NX windows would be super cool; and my nascent App could easily use
multiple NX windows, many of which have independent LVGL graphics rendered to
them. Bring it on!!
An window framebuffer would be a minor extension to the existing full
display framebuffer. If the framebuffer is not RAM backed then this driver
Window framebuffer driver would just replace the direct writes into the
framebuffer with calls to NX APIs to write the image. NX would write to the
correct position on the display, clip, and handle intersections.
Documentation:
https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem
Other than the initialization of the window and selection of the driver, I
don't think that the change would affect the application.
The driver would also have to handle a few callbacks like redraw (just
redraw the window if it a new part of the window is exposed) and other events
(like moving the window or keyboard or mouse input). Keyboard / mouse input is
another topic. These events go to the window that has focus. I would need to
think about that more.
I am interested in this topic. I am very retired now, but still willing to
help out.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]