On 10/12/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: ... > So the question is - how much effort do we want to put into the case > where there are multiple clients PLUS buffer resizes. Multiple clients > is a rare case in itself, and resizes are a transient varient on a rare > case. Also just what can we gain by putting effort into that case -- do > we get a behaviour that is actually any more sensible than just thowing > away the rendering of the additional clients until they get themselves > sorted out with the new buffer size???
As long as the app can render the final frame correctly based on the last resize event it sees, I think we're fine. We can't guarantee that intermediate frames will be fully consistent Core X rendering has this problem too to some extent: an application sees a resize event, sends a series of rendering requests based on the new size. The stream of requests isn't atomic with respect to subsequent resizing and this can result in, if not undefined, at least undesired results. To get consistent resizing, the windows manager and application have to implement a higher level protocol where the windows manager coordinate resizing with the application so that it doesn't resize again before the application has finished rendering the previous layout. Both compiz and metacity already implement this in cooperation with gtk+, and the same protocol can be used for opengl that care about consistent resizing. So in short, we're not introducing a new problem here, and it's a situation that can has has been solved. Kristian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
