guix

guix copied to clipboard

Is GuiX able to handle Partial Framebuffers like TouchGFX? Partial Framebuffers is a concept with at least two buffers. While one is transfered to the display, the others can be rendered and written. That works like a fifo and reduces the amount of needed RAM, because instead of a full screen framebuffer, two (or three) very small framebuffers are used.

Hello @thilofrank,

Support for this method of visible frame buffer update is in our task backlog and will be implemented for an upcoming update. Can you tell me, are you using a self-refresh display with internal GRAM? Just curious.

I use an ILI9341 spi display controller, that has GRAM included.

The documentation mentions Ping-Pong-Framebuffers. Is this the same?

Regarding GRAM- perfect. Regarding Ping-Pong buffers, related but not exactly the same. GUIX currently supports full frame-buffer size ping-pong buffers, so the application is writing to and updating the working buffer while the LCD refresh circuitry operates out of the visible buffer. This is really intended for architectures without self-refresh, i.e. the MCU or external LCD controller is continuously updating the LCD data. After each drawing sequence, the buffers are toggled. This is really implemented by the display driver, which also updates the GUIX canvas memory pointer after each buffer toggle.

The partial buffer design is similar, but each working buffer is N scan lines in size. GUIX already implements full clipping, so the idea is that we clip the drawing to N scan lines, shift this out to the GRAM, draw the next N scan lines, etc... If you have two small buffers, drawing to buffer A and shifting buffer B to the GRAM can happen in parallel. GUIX also keeps track of the canvas dirty area, so often a full screen refresh is not required. The partial buffer design only redraws the dirty scan lines with each refresh operation. This requires a logic change in the internal GUIX canvas refresh function, so we can't implement this only in the hardware specific display driver. That is the reason a GUIX update release is required to support this correctly.

The ILI9341 has a command to set its windows (x,y,w,h). If a partial framebuffer helds all data w/o the non-dirty areas, it can be flushed in one shoot. Is this your idea for the future?

Just wondering if there's been any update on this? The idea of partial frame buffers is quite appealing in memory-constrained scenarios.

@azeater we have this task in our backlog but it's not going to make into the July update release. We should be able to tackle this for the next update release after July.