[Libdlo] udlfb flush on close

Phil Endecott spam_from_libdlo at chezphil.org
Tue May 26 13:41:02 PDT 2009


Roberto De Ioris wrote:
> Phil Endecott wrote:
>> Now, how can we add double-buffering to that?
>
> If you follow the mmap+ioctl approach (as in the mplayer patch) you do not
> need a double buffer to reach good performance without flickering.

At a high resolution it will take a while to transfer the data.  
Transferring to a second buffer in the device and then swapping is a 
safe way to avoid artefacts that should not be difficult to implement.  
I'm glad that you're seeing good performance without it, but I don't 
think that will apply in all applications.

> But probably, to implement compression, we will need a second buffer in
> the kernel (to track pixel differences) that can have a lot of use (even
> if maintaining two such a big buffer would be overkill on embedded
> systems)

Have you investigated using the MMU to track which pages of the 
framebuffer have been written to?  If you can do this, you have a 
record of which lines need to be sent without needing any additional 
buffers or API changes.


Cheers,  Phil.






More information about the Libdlo mailing list