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

[Udo Giacomozzi]

Hello Martin,

Sunday, July 8, 2007, 3:12:46 PM, you wrote:

MG> 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.

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

That's the case! :) The duplicated code would have been the timer
call, but let's stop this discussion...


>> But whatever, using usleep(1000) should be fine in any case.

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

What I wanted was: allow a task switch, but don't exceed 1000 HZ on
systems that would be able to.


MG> The reference for function semantics is the POSIX standard,

There's
  man <function>
too...

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

The *performance* of a player is not a criteria. Running that same
movie with PP on a slow machine will show the same problem. PP would
not skip frames in that case, so we won't either. We can't fix a
"problem" making another one..

The reference for playback behavior is the proprietary player, not the
effects of one (fairly heavy) movie ;)

I'm totally against skipping frames, as this would introduce many
problems.


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

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

That's absolutely not a Gnash bug, it's just a badly designed movie.
The only fix for it can be: make Gnash perform better.


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

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

You mean technically? Should be feasible, but a bad idea anyway. It
may fix problems with one kind of movies, but introduce problems with
other kinds of movies.

Examples are movies that consciously use a exaggerated frame rate.
Also, animations in movies would not be smooth anymore. Think of a
movieclip that moves (or morphs) on the stage at a constant distance
per frame. When the renderer is slightly behind the nominal fps, you
wouldn't even notice it. When skipping frames, however, you would see
that the movieclip occasionally makes a jump.

BTW, I wonder if current Gnash version is still too slow to handle
these kind of presentations on modern CPUs...

Udo