It's a very rare application that can render half a frame to one sized framebuffer and the other half to another and expect to have a meaningful result.
It's also incredibly difficult to write a driver that produces any sensible result when the render-target size changes halfway through a frame. There are a bunch of reasons for this, including the fact that the driver will have unflushed command buffers referring to the old size that are suddenly invalid when a new size materializes. Basically one of the best things we ever did was stop checking the DRI1 sarea for window size changes except at swapbuffer and makecurrent times. Being able to resize windows without seeing mangled/garbage frames in the middle was a huge step forwards. My pet take on this is that we should go one step further and modify GLX semantics to allow a stretch blit on swapbuffers to scale the rendered image up/down to the new window size. There is no possible way to make sure that the driver always produces a frame that matches the new window size (as it may change in the middle of a frame, etc), this seems like by far the nicest approach from a users perspective. It disregards an aspect of the GLX spec - I'm interested to hear if anyone can figure out a way to square that circle... Keith ________________________________________ From: Michel Dänzer [mic...@daenzer.net] Sent: Friday, January 22, 2010 4:11 AM To: Francisco Jerez Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] [mesa patch 1/3] dri2: Event driven buffer validation. > > When the invalidate event is available, IMO the buffers should also only > > be invalidated after a buffer swap / front buffer flush, not 'in the > > middle of a frame'. > > > Event-driven applications want the new buffers immediately after getting > the resize event, otherwise they could try to draw outside the bounds of > the old buffers, and that rendering would be lost. I still don't see any benefit to changing the buffers while the app is rendering a frame, but I guess the problem is that the DRI2 code in libGL doesn't know if that's the case or not... ------------------------------------------------------------------------------ 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
