[ continuing discussion from directfb-users ] Ville Syrjälä <[EMAIL PROTECTED]> wrote: > My first idea would be to have the V1/V3 layer like any other layer and > just have a special HQV blit funtion that would be used if possible. I > don't know the hardware so this is just a gut feeling.
I think that could be done. I'm a little unsure about how to handle waiting for the HQV blit though. Is there an API spec for the interface to be implemented by gfxdrivers? I've never seen one and just have the code to go on. That's fine for making changes to what's already there but isn't really enough to tackle adding support for new functional blocks. Normally the HQV and video overlays work together to implement a double (or triple) buffering model. The application would typically write a frame (in YV12, YUY2 or one of a few RGB formats) and kick the HQV. It would then convert the frame to YUY2 and write it to the overlay's back buffer before flipping the buffers itself. That's the bit that I don't think really fits DirectFB very well. A simpler model could be implemented where everything is triggered manually by the application and DirectFB could choose HQV when the pixelformats or scaling suggest it. But, I could do with an overview of the general model in DirectFB, in particular how all the set/check state, sync, emit, and so on fit together. Is there such a document? Regards, Mark _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
