gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp


From: Martin Guy
Subject: Re: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp
Date: Fri, 6 Jul 2007 11:13:45 +0100

2007/7/6, Markus Gothe <address@hidden>:
        gui            : NullGui.cpp

Log message:
        Get rid of tu_timer n favor of boost, albeit ticks_per_second() might 
return nanoseconds, I donnu what the implication of this would be.

Hi Markus
 One implication is that boost::date_time becomes a required
dependency of Gnash, only for the NullGui. Otherwise it is not
required.
 In general I agree that tu_* should be dropped wherever possible,
but in this case there is no advantage: tu_timer is still used in lots
of other places. It would make more sense to do real-time timing
portability in one place (tu_timer.cpp) instead of using tu_timer
here, gettimeofday() there,
((microsec_clock::local_time()).time_of_day()).total_milliseconds()
elsewhere, at least for the realtime-since-start-of-movie stuff
(Date.cpp has other problems that tu_timer cannot help with)

  In general this NullGui code "could be improved".
- Infinite loops peppered with breaks are confusing. I know Gnash is
full of them, but they are error-prone and a sign of confused
thinking. It would be better to figure out what the loop terminates
on, then loop for that explicitly.
- A busy-wait with usleep(1) (currently making a call up to 1000000
times a second to very slow localtime code!) would be best replaced by
working out how long to delay for in absolute time and then calling
usleep with the right amount. Anyway, in windows here we have #define
usleep(n) Sleep(n/1000) so that has a true 100% CPU busy loop.

For now can you please revert NullGUi.cpp to 1.12, where the use of
tu_timer is a slight portability improvement on explicit use of
gettimeofday().

Cheers

    M




reply via email to

[Prev in Thread] Current Thread [Next in Thread]