On Fri, Nov 30, 2012 at 11:40 PM, Eric Anholt <e...@anholt.net> wrote: > The mixing of the factoring out of the protocol bits with the flush > change in this commit is irritating, but I'm fine with the overall flush
Ah, sorry, I based it on my previous series and didn't notice it was superfluous. > interface of this series for the current loader implementation. > > Long term, I think for what you're working towards you'll want the > dispatch threading that Paul has been working on, and dri.next for > communicating swaps to the server, then push the whole swapbuffers > request out of the loader and into that thread. At that point, all this > flush interface would be replaced with the swap request to the driver. I would prefer if the driver didn't have to implement the swap. My previous series had a more generic interface: void flush_with_flags(...., void (*finish)(void *data), void *data); The driver would then call the "finish" callback in the driver thread once the flushing is done. In this case, finish would be dri2XcbSwapBuffers and data would be its parameters. There was also the function void sync(__DRIcontext*) in case we wanted to wait until the finish callback is done, so that we can e.g. safely destroy the drawable or read the swap reply. Marek
pgpZpxmKwyjgh.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
