Hello Martin, Sunday, July 8, 2007, 3:12:46 PM, you wrote:
MG> 2007/7/7, Udo Giacomozzi <[EMAIL PROTECTED]>: >> 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 _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
