From: Greg H. <hu...@gm...> - 2005-05-25 22:49:55
|
Ah yes, this seems familiar. I definitely made some changes to the way that contexts were created/deleted on Windows. This had to do with the fact that contexts for pbuffers are created with a separate function on Windows which was only partially supported in Chromium (it sort of worked but didn't add the context to the hashtable because there was no "window info" when the special wglMakeContextCurrent function was called). On May 25, 2005, at 6:05 PM, ma...@co... wrote: > Brian, > > Thanks for the explanation - that's very helpful. > > >> The only time a context should be in the UNDECIDED state is when it's >> been created, but has never been made current. Perhaps the WGL code >> is missing an assignment to set the context's type in wglMakeCurrent. >> > > What if it's never made current!? > > Apparently, although it may be "wrong", what many (or at least 2) > "real world" > apps do is create a context, check some capabilities, and if it's > not up to > snuff, the context is deleted, without ever being made current. > > So, stubDestroyContext gets the context and does nothing to it, > since the > context type is UNDECIDED, and as a result the window stays up... > > > **So, what should stubDestroyContext do when the type is UNDECIDED?** > > > Thanks, > Jon > > > ------------------------------------------------------- > SF.Net email is sponsored by: GoToMeeting - the easiest way to > collaborate > online with coworkers and clients while avoiding the high cost of > travel and > communications. There is no equipment to buy and you can meet as > often as > you want. Try it free.http://ads.osdn.com/? > ad_id=7402&alloc_id=16135&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > -- Greg Humphreys, Assistant Professor Department of Computer Science, University of Virginia http://www.cs.virginia.edu/~humper/ |