Ok, now it's clear. So it means that currently only matrox driver is really proof against tearing in triple buffering mode. Thanks!
Best regards, Mike 2011/7/5 Ville Syrjälä <syrj...@sci.fi> > On Tue, Jul 05, 2011 at 11:26:47AM +0200, Michael Graph wrote: > > Hi all, > > > > I have an application which works in triple buffering mode and flips > buffers > > with DSFLIP_ONSYNC flag (DSFLIP_WAIT flag is not used) - it's based on > > df_andi scheme. If time of rendering one animation frame is less than > time > > between two VSyncs, it's possible to achieve following situation: > > - buffer number 1 contains already rendered animation frame and it's > already > > displayed on the screen, > > - next animation frame is rendering in buffer number 2 and when it's > ready > > Flip is calling - it returns immediatelly, physical buffers flip will be > > performed on next VSync, application starts drawing on buffer number 3, > > - next animation frame is rendering in buffer number 3 and when it's > ready > > Flip is calling - it returns immediatelly, physical buffers flip will be > > performed on next VSync. Note that none VSync comes yet, so buffer number > 1 > > is still visible, > > - application starts to render next animation frame in buffer number 1, > > which is still displaying. > > Result: tearing is visible on the screen. > > > > There can be few methods for solving this issue, so the question is: what > is > > the better method to fix it according to DirectFB design? > > > Or maybe 1st flip should be skipped in this case and 2nd flip > > should switch drawing buffer to number 2 instead of buffer 1? > > This is how it was designed to work. It's the reason dfb_surface_flip() > has the 'swap' parameter. Currently only matrox_bes.c uses it though. > > -- > Ville Syrjälä > syrj...@sci.fi > http://www.sci.fi/~syrjala/ >
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
