linguini1 commented on PR #17294: URL: https://github.com/apache/nuttx/pull/17294#issuecomment-3507484221
> Is this is anything like SAMA5D2, the framebuffer is continually sent to the LCD (hdmi in your case) but the fb app (and lvgl before they modified it after feedback from me) write to it whenever so the written data garbles the screen image. With lvgl it caused tearing of a spinner, for example.Lvgl now uses 2 alternating render buffers which it copies to the framebuffer when ready. But I still think it is in no way synchronised with a vertical sync, and wastes time doing a 1.5mbyte memcpy every frame.The answer lies in the arch fb driver code, probably via FBIOCTL (from memory; sitting in an airport coffee lounge right now lol)Regards,Tim. Well, @TimJTi, you've solved it! It looks like rendering to the frame buffer directly in `fb` was the culprit. I modified the code to render to a RAM buffer first and then `memcpy` all of it to the frame buffer at once, and the image is crystal clear! <img width="1013" height="1347" alt="image" src="https://github.com/user-attachments/assets/83e48008-7775-46b9-95d8-369944e8cf17"; /> I don't think there's a way around this issue with my implementation, it is the application's "fault" for trying to render to the frame buffer directly. I think I can probably improve this by adding DMA so the memory operations are faster, but for now it's inevitable. I've documented the issue with a warning in the RST docs. -- 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]
