Hello Martin, Friday, July 6, 2007, 12:13:45 PM, you wrote: MG> In general I agree that tu_* should be dropped wherever possible,
What's the problem with tu_timer? I interpreted it as a general Gnash tool for timing. Anyway, wouldn't it be best to have a dedicated .h just for timing purposes? MG> In general this NullGui code "could be improved". MG> - Infinite loops peppered with breaks are confusing. I know Gnash is MG> full of them, but they are error-prone and a sign of confused MG> thinking. It would be better to figure out what the loop terminates MG> on, then loop for that explicitly. The infinite loop design was taken to avoid calls to usleep() when the delay is 1. This will probably be the most used value when one uses the "-d" switch. This allows much better performance profiling because any call to usleep() will slow down Gnash dramatically. MG> - A busy-wait with usleep(1) (currently making a call up to 1000000 MG> times a second to very slow localtime code!) Not correct. usleep(1) does not really sleep a nanosecond. It just causes a task switch which on most architectures corresponds to a 10 milliseconds sleep (100 HZ). With other words, the usleep() call is just to release CPU resources to other processes and it does not matter what value was given to usleep and how fast the code is between the sleeps. MG> would be best replaced by MG> working out how long to delay for in absolute time and then calling MG> usleep with the right amount. usleep() just sleeps _at least_ the specified time (unless interrupted by a signal), which means the timing would be inaccurate in that case. MG> Anyway, in windows here we have #define MG> usleep(n) Sleep(n/1000) so that has a true 100% CPU busy loop. You mean because that equals sleep(0) ? On http://msdn2.microsoft.com/en-us/library/ms686298.aspx they say: "A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution." This sounds like 0% CPU to me. However I admit that I don't really thought about Windows when patching NullGui. Udo _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
