Partial Framebuffers about guix

[jdeere5220]

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.

[thilofrank]

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

[thilofrank]

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

[jdeere5220]

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.

[thilofrank]

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?

[azeater]

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

[jdeere5220]

@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.

[azeater]

Hi, sorry to revive a closed issue but I was wondering where this has been implemented/if it has been released yet?

[ting-ms]

@azeater Apologies for closing this issue. The mentioned feature hasn't been supported yet, but we will consider supporting the feature in the future. If you are working with hardware from ST, Microchip, NXP, or Renesas, you may also seek assistance from them for further guidance and support on this matter.

[ting-ms]

@thilofrank @azeater Is this feature still required? Could you provide information about the hardware you are utilizing and the specific scenarios in which you are employing this feature?

[azeater]

Hi @ting-ms - yes I would definitely say this is required. Any embedded system with memory constraints would greatly benefit from this. For example, using a 320x240 16 bit display requires a full frame buffer of 153600 bytes - on a small MCU with 256KB of RAM that's over half the RAM needed to update the display which could be a blocker in using GUIX.

@thilofrank mentioned TouchGFX but I've got experience with LVGL which also supports partial frame buffers and works quite well.

[ting-ms]

@azeater Thank you for your response. Are you currently in the evaluation stage, or do you have a production waiting for the implementation of this feature?

[azeater]

We are currently developing a product and are waiting on this feature.

[ting-ms]

@thilofrank @azeater The partial frame buffer is currently available in GUIX release 6.3.0.
For detailed instructions on how to use this feature, please reference the documentation Appendix D - Canvas Partial Frame Buffer Feature | Microsoft Learn.