gnash-dev
[Top][All Lists]
Advanced

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

[Gnash-dev] heart beats / fixed rate slices / VirtualClock


From: Udo Giacomozzi
Subject: [Gnash-dev] heart beats / fixed rate slices / VirtualClock
Date: Fri, 16 May 2008 23:09:47 +0200

[moved discussion from gnash-commit to here]

Hello Sandro,

Friday, May 16, 2008, 12:11:35 PM, you wrote:
SS> About the getTimer/Date things I'm not sure we can trust them.
SS> I mean, we already use a VirtualClock so we may pretend whatever we want,
SS> better tests would use a real clock (off-player) to check what happens.

I do and I don't like the virtual clock approach at all.
First, why would the Macromedia folks interpolate the system time,
when it is coarse anyway? I accept interpolation of getTimer(), but
for Date() it doesn't make much sense.

Anyway, I tried to create a testcase for this. We can't trust Date()
so we need something from the outside world. I used JavaScript,
because it's the simplest way to interact with a Flash movie:

A simple JS script tries hard to update a internal variable of the
Flash movie. At the same time the Flash rate checks the same variable
at the maximum possible frame rate.

http://www.nova-sys.net/temp/flash/movie.html

The flash movie shows the internal frame advancement rate and how
many times the variable had been updated.

I get 120 +/- 10 frame advances per second and 63 +/- 5 updates from
JavaScript. Note that the JavaScript timer is limited to this value
because of it's design (uses timer signals I guess). To verify the
JavaScript speed it is updated in the document title and you'll see it
matches the value reported by the movie.

When the movie is embedded with it's own window handle (wmmode="") in
the HTML page, then it also is limited to ~60 frame *advances*.

In either case you can send some signals to the browser by moving
quickly the mouse, which will result in a slightly higher frame rate
(~70 verified fps).

To me this is a clear indication that the proprietary player really
executes the code at the rate it claims.

-1 for VirtualClock


SS> Also note that the 'aliasing' problem would still be there for a 12FPS
SS> movie loading a 13FPS movie, as it's been reported each loaded movie
SS> is expected to run at its own speed..

We know that the proprietary player can play fast movies inside slow
movies. But we also know that the difference matters (I think that's
where the 1/10 comes from), meaning that a 120 fps movie will play at
10 fps in a 1 fps host movie IIRC.

So, -1 for the "slices" solution too (unless we modify it somehow).

Udo

PS: Tested under WinXP with FireFox and IE using a dual core processor





reply via email to

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