On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez <curroje...@riseup.net> wrote: > Kristian Høgsberg <k...@bitplanet.net> writes: >> No, it sounds good, I'm happy that you're looking into this. I'll >> have a closer look tomorrow, but what I've had in mind for this kind >> of thing was that we could just allocate the new buffers up front in >> the X server. Then, instead of an invalidate event and a subsequent >> DRI2GetBuffers, we'll just have a "here are your new buffers event", >> so we avoid the round trip. > > Yeah that's sensible, the only problem I see with doing things that way > is that it doesn't give the driver an opportunity to flush its rendering > queues before swapping buffers, so some of it could be lost buried in > the old buffers.
Right. Another option is to tell the client about new buffers in the DRI2SwapBuffer/DRI2CopyRegion reply instead - or to kill two birds with one stone, make DRI2SwapBuffers/DRI2CopyRegion one-way requests (that is, requests without a reply) and then send an event instead. This lets the client do other things while waiting for the server to reply, and we'll wait for the event to arrive in the GetBuffers callback from the driver if it hasn't already. The event will always be sent in response to either DRI2SwapBuffer or DRI2CopyRegion, which addresses your concern about sending the event to everybody. The client must wait for the event before it starts rendering the next frame since it could receive new buffers and in any case the server needs to submit the back->front blit first (which is the reason DRI2CopyRegion is a round-trip). That would be the ideal solution as far as I know, and if we're changing things, this is what we should go for. cheers, Kristian ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
