Re: [Mesa3d-dev] [mesa patch 1/3] dri2: Event driven buffer validation.

[Francisco J. <cur...@ri...>]

Keith Whitwell <ke...@vm...> 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