On Fri, 2010-01-22 at 09:40 -0800, Francisco Jerez wrote: > Keith Whitwell <kei...@vmware.com> writes: > > > 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. > > > > As Michel said, that isn't what this changeset does, the new buffers > don't kick in until the application becomes aware of them. And that > shouldn't happen "mid-frame" unless the application is expecting it to > happen at that point.
OK, understood. > > 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. > > > Wouldn't that mean modifying the viewport transform behind the user's > back? Or would the "window" dimensions stay constant? No, I mean turning SwapBuffers into a stretch-blit to bridge the gap between whatever we thought the window size was when we rendered the frame to what it really is when we do the swap. Michel doesn't like this too much, though... Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
