Denis Oliver Kropp ([EMAIL PROTECTED]): > Quoting Billy Biggs ([EMAIL PROTECTED]): > > 1. I need to know which field is currently being displayed on the > > DisplayLayer so that I don't draw to it (and tear). I think this > > should go as part of IDirectFBDisplayLayer. I will add it using > > SetOpacity as my example. I don't think it makes sense as part of > > IDirectFBSurface since for a non-output surface, it could be, say, > > displaying its even field but being blit into the odd field of the > > output. I think it would be confusing. > > Every IDirectFBSurface has a current output field. You can switch it > by calling SetField(). If it's the surface of a layer, the current > output field of the layer will be set (for deinterlacing with BES). > You can also blit from non-output surfaces using DSBLIT_DEINTERLACE, > it will blit the current output field with twice its height into the > (non-interlaced) destination surface. Maybe the current output field > of layer surfaces should automatically be changed each vsync if the > hardware switches them itself (e.g. in interlaced mode). Adding > GetField() would make sense then. When doing deinterlacing on the BES > the fields are changed by software (via SetField()).
I appreciate the SetField() call, although it sort of implies there is only one way to deinterlace. I'm not sure how you intend to support software deinterlacers, if at all. For the GetField(), it only makes sense for the output surface, so it's unclear to me that IDirectFBSurface is the right place. For a non-output surface, it maybe being blit into a rect which flips the field parity, so GetField() is impossible to return without knowing intent. If that's true, why not put it as part of IDirectFBDisplayLayer, since that is who controls the output surface. > > 2. Why is WaitForSync part of IDirectFB? The G400 for example has > > two heads, each with a separate sync signal (and VBI interrupt!). > > I'd really like to use both at once. I'd like to move WaitForSync > > into IDirectFBDisplayLayer. If it's there, I'd like it to also > > return which field is being displayed (have the information > > available in two places), since I think it would be cleaner. > > DirectFB doesn't really have support for multiple heads. Moving > WaitForSync() into IDirectFBDisplayLayer would be a half solution, > because several layers are on the same head. > > We could discuss on a new interface like IDirectFBScreen. If several layers are on the same head then fine, just let them all get the same signal. > > 3. Right now, an interlaced IDirectFBSurface means nothing except in > > special cases. I'd like to update all the drawing functions so that > > they can act on fields independently, otherwise I might tear etc. > > So, ClearField, BlitField, DrawRectangleField, etc. Thoughts? > > Should maybe the clip rects be updated so that they have a stride? > > It's awkward that these functions work on rects rather than starting > > position+stride as the latter is much easier to work with when > > dealing with interlaced buffers (just set stride=linestride*2, > > height/=2). > > As both fields together are one image (either deinterlaced or on an > interlaced output) I don't think that drawing to only one field would > make sense. Maybe SetField() should be called SetOutputField(). I don't understand what you mean by this. Each field is definitely its own image. If I'm drawing, say, a text crawl at the bottom of my screen, on each field I will advance the text further in the crawl direction. Ignoring tearing/single-buffering issues (clearly if you're single buffered, you can't write to both fields at once), if you're fading out a video, to do this smoothly you want to composite-to-black each field separately to get a smooth fadeout. -- Billy Biggs [EMAIL PROTECTED] -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
