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()). > 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. > 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(). -- 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.
