Quoting Billy Biggs ([EMAIL PROTECTED]): > > 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.
The blitting method is an accelerated software deinterlacer. Other software deinterlacer can be implemented in the application using Lock() on the surfaces. > 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. What about GetOutputField() and SetOutputField()? > > > 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. Ok, if WaitForSync() stays the only screen method there shouldn't be a new interface. > > > 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. Makes sense, I didn't think about animated graphics. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
