On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin<a...@pobox.com> wrote: > On Fri, Jun 12, 2009 at 06:58:44AM +1000, Dave Airlie wrote: > | All I've got is the glXMakeCurrent error to go on, > | GLXBadCurrentWindow is generated if there are pending GL commands for > | the previous context and the current drawable is a window that is > no > | longer valid. > > I'm unsure what the intent was there, because the GLX spec never defines > "valid" and uses it in several different ways. (For example, "valid" > PBuffers are different from "valid" windows are different from windows > with "valid" XIDs.) > > | Now if something was meant to implicitly flush the command stream on > | window teardown then how would this ever happen. > > On the other hand, if there's no mechanism for implicitly flushing the > GL command stream on window teardown, then whatever problems this error > is designed to address can happen every time a window is closed. I > would expect to find something in the spec that says "You must execute > (SwapBuffers|Flush|Finish...) before destroying a bound window or > such-and-such bad things can happen." Trivial test programs would have > been failing since day one.
Well usually when the window is torndown, we exit straight away afterwards, normally you don't keep going, however the glean test case does another test which opens a new window and rendering context and calls MakeCurrent on it, thereby triggering the above failure case. esp after it has done rendering on the previous context and then blown away the window without flushing or swapbuffers. I'm not sure how many apps regularly teardown windows and contexts and restart them. In fact its been broken in the X server for a while (it would crash) and the only think I can make it happen with is the glean test case :) > What happens when one X client destroys a window that another one is > using for GL rendering? The destruction of the window has to be > postponed until it's no longer bound to an RC, or the GL command queue > has to be redirected to a black hole, or GL rendering has to be > terminated by error somehow. Or something else. If the window is destroyed the app normally gets a SIGPIPE and dies soon after. Dave. > > So my guess would still be that a mechanism has to exist, but maybe I've > missed the key phrases in the spec. > > Ian, your knowledge of this stuff is a lot more recent than mine . Any > advice? > > Allen > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
