[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