Kristian Høgsberg <k...@bitplanet.net> writes: > On Sat, Jan 16, 2010 at 4:58 PM, Francisco Jerez <curroje...@riseup.net> > wrote: >> The current buffer validation approach (AKA the DRI2 glViewport hack) >> is both incorrect (because a compliant OpenGL application may opt for >> the identity as viewport transform and work with window coordinates >> directly) and inefficient (some programs have the habit of calling >> glViewport several times per frame (e.g. OpenArena), causing many >> unnecessary roundtrips). >> >> This changeset gives DRI2 the ability to report drawable changes in an >> asynchronous way, but it's a bit intrusive so I expect all sorts of >> complaints to come. > > 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. If we killed DRI2GetBuffers, then I think we would want something like a "please keep me informed about this drawable" request and a "i don't care about this drawable anymore" request, because we don't want to bother clients when they aren't actually rendering to the affected drawables. (Resurrecting the old DRI2Create/DestroyDrawable would also do). I'll be happy to rewrite the patches that way if you guys think a somewhat smaller resizing latency is worth the somewhat greater complexity (and you have a solution for the flushing issue). BTW, I suspect there might be some problems with the X server DRI2 code so please don't look at it so closely yet... (or maybe just my usual 5AM paranoia) > > Thanks, > Kristian
pgpzaz8FHs8q3.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
