> "fullscreen in a window" means a window covering the whole screen?
Yeah it is basically what xine and mplayer are doing. Take the primary layer create a fullscreen surface and strechblit inside preserving aspect ratio with black borders. That would be the default mode of directfbsink if launched from the console command line for example. In that case i would init all the directfb library from the plugin and create what i need. > > - Applications passes a precreated window where i should draw. > > Why not just pass the surface to the plugin? That would of course not be > enough for using the overlay keyed to a window, or using other layers at all. > > While I'm thinking that IDirectFBSurface::SetDescription() would require a lot > of checks if the description could be applied, another simpler method > IDirectFBSurface::SetPixelFormat() could be done much easier. > > What about choosing the right surface size? Using a surface with the original > video content size would save scaling, too (in addition to saving color space > conversion). > > Scaled windows will be added soon. For now you should create an intermediate > surface within the plugin (with best size and format) and Blit or StretchBlit > from that, unless you are using direct decoding into a layer's surface, of course. Indeed the best would be to create a surface where the data will be directly decoded by gstreamer in the correct size and pixelformat. But still the plugin would need to StretchBlit that to a window's surface to actually draw image. So maybe the app should pass a created window and the display layer so that i can create the surface i need. Thanks for your thoughts on that. cheers, -- Julien MOUTTE (aka Dolphy) Homepage : http://dolphy-tech.net
signature.asc
Description: This is a digitally signed message part
