juj

> The framebuffer/GPU updates are driven by the display frequency (in most cases - there is a slight proviso on 90 and 180 display rotations), so vsync would probably be...

> If I understand what you are asking for, it's like a callback when the image changes, and I don't that would be particular easy/efficient to implement. I don't think...

Thanks for the detailed description! This is very informative. > If you present it a new image to display on an element before the VSYNC, then it will be applied...

Searching further, I find https://github.com/raspberrypi/firmware/issues/355, and perhaps what we're looking for here is to hook in the middle to get an event callback from functions `vc_dispmanx_update_submit` and `vc_dispmanx_update_submit_sync` that *someone...

> My example of the video wall has 16 clients (probably MMAL video_render components running on the GPU, but could be independent Linux apps) plus the Linux frame buffer. Each...

> To my mind firmware#355 is unrelated. They were requesting a callback when their own resources actually got updated, and had hit a genuine bug. Oh sorry, linking that was...

> DispmanX absolutely allows multiple clients. > Find a video clip, and try > > omxplayer --no-keys --refresh --loop --win "0 0 640 360" file.mp4 & > omxplayer --no-keys --refresh...

Let me come back to the originally posed questions, now I think I understand the original answers from @6by9 better. If I was to design this kind of "eager" compositing...

I have been working on porting fbcp-ili9341 to support bigger 480x320 displays and Pi Zero in addition to 320x240/Pi 3, and increasingly find the project juggling between high CPU consumption...

fbcp-ili9341 has added a statistics option to display a histogram of the amount of stuttering that occurs. The option looks like this in practice:  The above picture is from...