On Samstag, 8. Oktober 2005 13:44, Ville Syrjälä wrote: > On Sat, Oct 08, 2005 at 12:02:23PM +0200, Denis Oliver Kropp wrote: > > Quoting Ville Syrjälä: > > > On Sat, Oct 08, 2005 at 09:02:36AM +0200, Stefan Lucke wrote: > > > > So I think I know how to separate a frame into separate field buffers. > > > > If a given frame has 576 lines I need 2 surfaces of 288 lines. Drawing > > > > has to be done with stretchblit from YUV2 (field1) surface to an RGBA > > > > surface, which has been allocated with DSCAPS_SEPARATED, upper half. > > > > Same has to be done for field2 (RGBA lower half). > > > > > > That should work. But it would be better to add proper support for > > > independent field blitting to DirectFB. > > > > Shouldn't be more than another blitting flag, because there's already > > a SetField() that selects the field to blit from using DSBLIT_DEINTERLACE. > > One problem with SetField() is that it's already used for deinterlacing > with layers. Using it for field based blitting would make it impossible to > use both features at the same time. > > > So DSBLIT_DEINTERLACE would be a workaround for you in the meantime. > > > > > > Or is this possible with one stretchblit from YUY2 DSCAPS_SEPARATED > > > > allocated surface to one RGBA suface with the same capability ? > > > > > > That should work too. > > > > If both surfaces have DSCAPS_INTERLACED the driver could automatically > > preserve interlaced content. DSCAPS_SEPARATED shouldn't be the indicator > > for this, but of course it presumes interlaced. > > > > > > At least a simple test for setting the CRTC2 layer configuration with > > > > DSCAPS_SEPARATED set, failed. > > > > > > That's because I didn't add support for it in the driver. The hardware > > > does support it though. > > > > Could be nice for decoding or capturing with hardware that doesn't support > > interleaved frames. > > > > > > Setting that flag to the source YUV2 > > > > surface had no visible effect on the stretchblit operation. > > > > > > Currently DSCAPS_SEPARATED only affects DSBLIT_DEINTERLACE behaviour. > > > > Blitting from a surface with DSCAPS_SEPARATED to one without could > > interleave the fields, but it wouldn't make sense anyways if the > > destination doesn't have DSCAPS_INTERLACED. > > > > Also, until now every "conversion" has to be explicitly indicated using > > blitting flags. Maybe we should keep that and don't do anything > > automatically. > > If so, we need some flags like DSBLIT_INTERLEAVE, DSBLIT_INTERLACED or even > > add a new group of flags for all interlaced related stuff regarding blitting > > and drawing. It might be useful, to fill a rectangle, but only writing to > > one > > field to preserve performance if the other (invisible) field is updated > > afterwards, i.e. for rendering interlaced games etc. to have 50 felt FPS > > with > > only 25 full frames rendered. > > For drawing something like DSDRAW_FIELD would be enough. It would mean > draw to one field only. > > For blitting I'm not sure if one or two flags would be needed. One flag > would indicate that the destination is a field. The other flag would > indicate the same thing for the source. That would allow the following > combinations: > > 1. frame -> frame > 2. field n -> field m > 3. frame -> field m > 4. field n -> frame > > Case 4 one is obviosly the same thing as DSBLIT_DEINTERLACE. If we > preserve DSBLIT_DEINTERLACE then only one flag might be enough, the > flag indicating that destination is a field. Whether the source is a > field or a frame could be determined from DSCAPS_INTERLACED. However that > would not allow blitting the wholle interlaced source frame to > one destination field. > > I think the interleaved <-> separated conversion could be implicit.
I guess and my whish from application side is, that it should be as transparent as possible (handling field interleaving and separation during blit just on specs of given surfaces). > > Oh and that reminds me that currently drawing to separated surfaces with > hw accel is basically broken since we can't ping-pong between the fields > like the sw code does. Easy stuff like FillRectangle() would be doable by > doing two fills but lines, triangles etc. aren't that easy. -- Stefan Lucke _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
