|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Flipping troubles - videolayer, crtc2
> > > 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 email@example.com with "unsubscribe directfb-dev" as subject.