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

[Martin Guy]

2007/7/7, Udo Giacomozzi <address@hidden>:

> I dislike endless loops too, but sometimes (when the loop is very
> short) they can make the code more readable IMHO.

In general loops should enter at the top and exit at the bottom
always. The only normal reason to break in the middle is when you need
to iterate N-and-a-half times: ABCDABCDABCDAB every time the loop
runs, as an alternative to duplicating the AB code either before or
after the loop.

NullGui.cpp now seems to have two nested loops: a while(1) inside a
while(true) with multiple breaks out of each. This stuff looks like
more like what one would write in assembler or BASIC!

Whether something is "readable" or not can only be judged by someone
else who is trying to read it. Of course it's "obvious" to the person
writing it at the time they write it. As a reader, I'm giving you
feedback right now that infinite loops with breaks in them are opaque
and worth replacing in your personal collection of programming idioms
with clearer ones.
If you try coding without ever using them for a while, it will seem a
little awkward to you at first but you will force yourself to learn a
richer set of idioms... unless you are writing a loop that really will
run forever, or until killed by an interrupt of course!

> MG> switch (foo) {
> MG>   case 0x00: bar = 0; break;
> MG>   case 0x01: bar = 1; break;
> MG> ...
>
> This was real code?? :-O

sever/asobjs/Global.cpp, removed 1 Feb 2007 (I can't get it right now
cos cvs.savannah is down :(
Actually it was switch(hexcode) {case 0x20: c=' '; break; for all
URL-encoded ASCII characters. Three pages of code replaced by one
assignment. Mind u, the whole function has gone now since there
someone else knew of a decode-URL-encoding function on the library,
replacing the whole function with a single line - even better!

> Hmm, I referred to the description of the Linux kernel docs itself
> (some documents about the scheduler internals, including 2.6
> preemptive kernel).
>
> But whatever, using usleep(1000) should be fine in any case.

It depends what you are trying to achieve. It's ok if you want to
suspend program execution for at least 1 millisecond (where "at least"
may mean "far more than"!)

The reference for function semantics is the POSIX standard, not the
scheduler internals of one (fairly hacky) implementation. If you learn
from studying one implementation, you end up with all sorts of
misconceptions about what function calls actually mean, based on what
the (maybe broken) implementation did on the box you learned on. But
your code will break whenever it is ported to a new environment.

> AFAIK in kernel 2.4 this was still a hard coded value, but I could be
> wrong.
I think so too, I wasn;t certain and couldn;t be bothered to fetch the
2.4 kernel, unpack it and check.

> >> while (1) { usleep(1); }    // process will show 0.00% CPU usage
> MG> Yes, that does surprise me
> You're not surprised anymore now, I hope? :)
Just shocked now, not surprised any more :)

> I'm sure PP is not skipping frames (except for Video maybe). When the
> CPU is too slow to handle the rendering, then frame rate decreases
> (just like it happens with Gnash).

Yes but the PP (ta!) is much much faster than Gnash, so it is much
more of a problem for us. Several bug reports are really about Gnash
being unable to keep up with real time.

> However, I'm not sure what sounds problem you are talking about since
> normally sounds samples are synched to frames...

Short sound effects maybe, but many cartoons/presentations have one
long MP3 soundtrack and rely on rendering running at the correct speed
to stay in sync.

Just an idea that would make it run all movies at full speed
immediately while we get round to speeding up the basic code. It would
make the minimum CPU requirement drop through the floor in one shot.

Does anything depend on every single frame actually being rendered to
the screen, or is it possible to perform two frames of object motion
and then render the changes?

   M