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

[Udo Giacomozzi]

Hello Martin,

Saturday, July 7, 2007, 1:21:18 PM, you wrote:
MG> The problem is the tu_ which stands for Thatcher Ulrich. I guess there
MG> should have been a smiley there.

Come on, if that's the only problem, then just rename that
file/function..!?


MG> Imagine if I went round writing functions called martin_this and
MG> martin_that... how would that look?

If you invented some revolutionary, famous function then I would not
have any problem with a mg_whatever() function ;-)


MG> It's a problem of egotism, which is generally a damaging thing in
MG> programming since it tends to make people defend their territories
MG> rather than concentrate on technical merits in a detached way.

Honestly, I think you're actually making a problem out of it. The name
of the file/function is badly choosen. Ok, let's change that. However,
the code itself is fine and no reason to go for big libraries like
Boost. After all, we're just talking about simple timing functions...


MG> There is egotism in the current battle of the timers too - look how no
MG> one can bear to be seen to have made a mistake.

Indeed, who made a mistake? There are various ways to solve a problem
(techically speaking). I agree we should use a common code base for
timing purposes (tu_timer seemed to be that, for me). Anyway, I don't
recall any earlier discussion about timers..


if (delay >> 1) usleep(delay); would have done that for you.

MG> An infinite loop with breaks is not a design, it is a mess. If you
MG> understand your problem before you try to code it, you can always find
MG> an elegant and clear way to express the solution.

I was wrong in my previous post. The endless loop is used to avoid any
call to usleep() when the timer reports that we're already late
(regardless of _interval value). Well, yes, I could have coded this
with a do..while and an additional "if" but come on, it's just 5 lines
of code... don't we have other problems? You are always free to commit
a better version...


>> 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)

MG> Thanks, I didn't know that. It turns out that 1000 usleep(1)'s take
MG> 7.4 seconds realtime here on a fast laptop in X with an open browser,
MG> 4 seconds on a idle machine with exactly the same OS. CPU idle time
MG> was 98% total in both cases.
MG> That's pretty unreliable.

usleep() is *not* a timing function. It's primary purpose is to tell
the system scheduler that the process is not going to do anything
within the next X nanoseconds. The scheduler then gives the next
process the running state.

When the scheduler is done with all "running" processes, it checks if
the usleep() time has finished and if so, gives the process some CPU
time (a "time slot").

AFAIK all normal i386 systems use a 100 Hz timer (there is a "HZ"
macro in the kernel) that drives the scheduler, ie. a process that's
never calling usleep(), select() or similar function will be
interrupted by the scheduler anyway when the 100 Hz timer fires, ie.
it's time slot ends.

In theory, when absolutely no process on your system want's to do
anything (ie. all are usleep()'ing) then usleep() might return
earlier.

In reality it's a bit more complex, but you get the idea..

MG> I've seen clock interrupt vary from 18Hz (the MSDOS RTC interrupt) to
MG> 1000Hz (Linux with low latency set). I guess your own Linux kernel was
MG> configured for 100Hz. Other OSs may do anything.

Correct. Anyway usleep(1) is a common way to cause a task switch that
won't return until all other processes with the same priority have got
their chance..

while (1) { }               // burns CPU
while (1) { usleep(1); }    // process will show 0.00% CPU usage


MG> However I suspect I've missed the current purpose of timing in
MG> NullGui here. 

The loop tries to do the most precise timing without causing needless
100% CPU usage.

Pre-1.11 versions did just wait _interval time between the end of one
frame and the start of the next one.

Example:
_interval = 40 ms (25 fps)
rendering needs 25 ms
results to a effective inter-frame time of 65 ms (15 fps).

Version 1.11 changed this so that _interval kept as long rendering
permits. Following changes were just about replacing the non-portable
gettimeofday() function.


MG> I was assuming it was an attempt to get the timing code correct so as
MG> to be able to use the same algorithm in the functional GUIs (at
MG> present every one does timing in its own different way).

Because there are different circumstances. The GTK GUI uses GTK timers
which should the most friendly way in a GUI-based world, which is
events-based.

The FB GUI uses the same method as the NullGui, except that it does
not use while(1) (hence causing a task-switch between frames in any
case) and it does not use tu_timer. I'd like to change the latter in
favour to some generic timing but one has to tell me where I can find
that. (I'd opt for tu_timer renamed to whatever name you prefer).

IMHO, the only use for NullGui is to do tests and to do performance
timining, that's why it should do correct timing. A real world GUI
(like FB) should not "freeze" the system just to play the movie at the
correct speed.

MG> It seems instead that it's being used for brute-force execution
MG> profiling of everything except rendering, by running the CPU at full
MG> speed and seeing how many realtime FPS (or whatever) you gets while
MG> little changes are made here and there.

Indeed.


MG> A more accurate way is to perform a fixed-size task and use the "time"
MG> command to see how much CPU it uses, as measured by the kernel.
MG> You could then use an efficient and accurate timekeeping design and
MG> your results will be valid for the non-null GUIs too.

Yes, you're right. However "time" just reports summed up results. The
new FPS printing code allows to analyze the movie while watching it.
Also, you would need some stop-after-X-frames option otherwise how
would you test endlessly looping benchmark tests?


MG> Better yet if we used framedropping: run the SWF/AS code for every
MG> frame but only rendered the graphics if the previous rendering has
MG> completed - the same technique that mplayer uses to keep audio/video
MG> in sync on slow CPUs. That would pretty much guarantee that movies run
MG> in real time regardless of the CPU power or rendering speed you have
MG> available.

That could be done, but would not match the PP behaviour which does
not do that. Any user would notice the difference, so I don't think
it's a good idea.

Udo