[directfb-dev] Re: Flipping troubles - videolayer, crtc2

["Jiri Svoboda" <jiri.svoboda@seznam.cz>]

> > > Setting backbuffer to main memory disregards the FlipBuffer()
> > > command, but instead calls dfb_back_to_front_copy(), which is 
> > > essentially a blit command.  Is the blit for YUV planars 
> > > fixed in 0.9.11?  Maybe this is the reason why flipping from 
> > > a system backbuffer does not work.
> > > 
> > 
> > After upgrading to latest CVS with YV12 BitBlt support the "new" 
> > implementation with backbuffer in system memory works OK.
> > 
> > So let me summarize (all is for videolayer):
> > 1) front buffer & back buffer in video memory, frame 
> written directly 
> > to back buffer by sw -> has big troubles, looks like wrong 
> buffer is 
> > obtained or displayed
> 
> The flip on the BES will take effect during the next vertical 
> retrace. Please try dfb->WaitForSync(dfb) after flipping or 
> DSFLIP_WAITFORSYNC as a flag for Flip().

Flip is always performed with DSFLIP_WAITFORSYNC.
	DFBCHECK (primary->Flip (primary, NULL, DSFLIP_WAITFORSYNC));

> 
> The vsync handling during flipping (before/after) should be 
> cleaned up. There should be a unique API for the different 
> behaviours with different hardware. DSFLIP_ONSYNC_WAITING 
> (waits until flip is executed on vsync), 
> DSFLIP_ONSYNC_SCHEDULED (returns immediately but flips on 
That would be nice :-) I will be able to render next frame immediately
and not waste cpu time. But it leads to tripple buffering (1-displayed
(old front buffer),2-wainting to be displayed (actual frontbuffer),3-new
backbuffer).
> vsync) and DSFLIP_IMMEDIATE (default?) may be more useful.
> 
> > 3) front buffer & back buffer in video memory, frame written into 
> > temporary surface (in system memory) than blit to back 
> buffer -> works 
> > OK
> 
> Are you doing a flip after the blit to the back buffer?
Yes. I perform always flip with DSFLIP_WAITFORSYNC after blitting.
	DFBCHECK (primary->Flip (primary, NULL, DSFLIP_WAITFORSYNC));

> Maybe you are locking the surface without the DSLF_WRITE flag 
> (case 1)?
Buffer is always locked with DSLF_WRITE.
	DFBCHECK (frame->Lock(frame,DSLF_WRITE,&dst,&pitch));

Where frame is either overlay in case 1&2 or temporary surface in case
3.
Eg. frame==primary for case 1&2.

I lock it for reading only in case of memcpy bitblt for YV12 surfaces.
Which doesn't happen for current version from CVS.

Let me say that case 1 is working for primary surface (for mga CRTC1)
created with flipping flag via
 dsc.flags = DSDESC_CAPS | DSDESC_PIXELFORMAT;
 dsc.caps  = DSCAPS_PRIMARY | DSCAPS_VIDEOONLY | DSCAPS_FLIPPING;
 ....
 dfb->CreateSurface( dfb, &dsc, &primary ); 

But this has troubles on CRTC2 of mga - surface is created, but flip
fails because panning is not supported by framebuffer. This is not very
nice - in previous versions creating such a surface failed   on
CreateSurface. This was better in my opinion, beacause if I'm allowed to
create such a surface I should be also allowed to flip it otherwise
don't let me create it.

				JS



-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.