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. 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. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
