From: John T. <nu...@me...> - 2011-02-24 08:05:54
|
On Wed, Feb 23, 2011 at 10:56:12PM -0600, Jason Wilkins wrote: > > I did say that glutPostRedisplay should have some sort of guarantee > that the screen will be redraw sometime soon. The way it is > implemented now it can literally be put off indefinitely. In excruciatingly badly written applications only. For the last time, callbacks are supposed to flip some state bits here and there and get the hell out of dodge. If you want something much more than that, spawn a thread, signal a condvar to wakeup a sleeping thread to do the work, drop a char in a selfpipe to wakeup a sleeping process to do the work (or the nearest equivalent in the broken operating system you're using), etc. > Sure it is the users fault. Indeed, end of story. Now for the second change you're proposing, the interleaved timer processing thing, as long as you don't break code or semantics with that change, I don't see what's the harm in it. I don't see much point in it either, but be my guest. A short benchmark would help you make your point to the maintainer (and all the rest of us) and make your patch easier to swallow. Try to measure timer processing latencies, and input event handling latencies, with various callback and redisplay delays to make sure we're not regressing on the common usage to help the unusual case of heavy callbacks. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |