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. > 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? > 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
pgpQ1nN2IwDcS.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
