Michel Dänzer <mic...@daenzer.net> writes: > On Tue, 2010-02-16 at 19:22 +0100, Francisco Jerez wrote: >> Keith Whitwell <kei...@vmware.com> writes: >> >> > On Tue, 2010-02-16 at 09:45 -0800, Francisco Jerez wrote: >> >> So far the frontbuffer was only being flushed on st_glFlush and >> >> st_glFinish, however, a co-state tracker may need to make sure that >> >> any frontbuffer changes are already on its way to the actual front. >> > >> > I'm not sure this is true -- GL spec states that rendering to GL_FRONT >> > is not necessarily visible until after GLFlush() or GLFinish() has been >> > called. That seems to match the current behaviour. >> > >> We need to do this before throwing the current fake front away and >> allocating a new one: Otherwise, if there's any unflushed rendering it >> will be lost. > > I think a better solution for that would be to only update the fake > front buffer on a glFlush.
That wouldn't work with an event-driven GL application (discussed here: http://marc.info/?l=mesa3d-dev&m=126416503326871&w=2).
pgpNEoVp9ypqJ.pgp
Description: PGP signature
------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
