ghaerr commented on issue #18566: URL: https://github.com/apache/nuttx/issues/18566#issuecomment-4642386041
> What is the decision on the build level is the SCREEN_PIXTYPE and SCREEN_DEPTH. Generic MWPF_TRUECOLORARGB covers probably everything imaginable but can demand too much memory on really small targets in some buffer etc. The current "framebuffer" driver scr_fb.c is a wrapper which is used to `mmap` the hardware framebuffer into process memory space. In many cases, the framebuffer family of "subdrivers", for which there exists one per each bits-per-pixel hardware (1, 2, 4, 16, 16, 24, 32) that might currently be in use at framebuffer open time. The standard framebuffer driver then selects the appropriate subdriver for low-level drawing primitives. Thus, hard-selection of SCREEN_PIXTYPE or SCREEN_DEPTH isn't usually necessary, as the screen driver will set a working MWPF_TRUECOLORARGB vs MWPF_TRUECOLOR_ABGR, MWPF_PALETTE etc after querying the OS/hardware. This only costs extra code space but is useful for developmental testing. For very small size deployment versions, various subdrivers can be removed from the executable making it smaller, but not able to run on as large a variety of framebuffer pixel formats. > Bitmap depth and framebuffer depths are independent so even with MWPF_TRUECOLORARGB API choice it is possible to choose small BPP options. But colors remapping and lookups can slow things down and 8 bit palette use directly on the API level can be better choice for such systems. True - Microwindows generally tries to carry around device-independent colors as 32-bit MWCOLORVALs, then convert them as necessary, which can take time and/or use excessive memory on systems not running 24- or 32-bit RGB. Options exist for applications to create pixmaps in any subdriver-supported pixel format however, which allows images to be created and blitted without having to translate to/from MWCOLORVALs. This can be discussed more after the NuttX initial port is running and application requirements are better known. > If you use the frame buffer driver at /dev/fb0, then you are committing to a single user solution. This writes directly to the hardware with no serialization and so is no suitable for a mult-threaded solution. The Nano-X API allows for applications to either request the NX server to draw unbuffered onto the framebuffer, but also supports automatic double-buffered windows which are fast-blit at expose time. A third option allows for permitting an application to gain a hardware pointer to a rectangular window of the framebuffer, which is useful for direct video output, etc. This is all assuming the "standard" framebuffer driver; an alternate screen driver can do anything desired. However, Microwindows and Nano-X drawing generally assume older "software-style" drawing, rather than the newer "composite-style" drawing used by Wayland and more modern graphics engines which take advantage of hardware GPU blending ops, etc. -- 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]
