CPU Creating Objects vs Modifying Object Properties

On Feb 1, 1:07 pm, timothytoe <timothy... (AT) gmail (DOT) com> wrote:

On Jan 31, 5:17 pm, Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> wrote:

Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> writes:
And that's disregarding the fact
that you're displaying *each frame* for *every* call to run()

Never mind, I misread your code.

It still doesn't make any sense, though.

Joost.

Are you saying time-based animation doesn't make sense? There are a
LOT of videogames out there that work that way.

No, he's not. But setting two setIntervals in motion that both call
the same function may well have unexpected results. Contrary to the
"two thread" inference, the two will never call the function at the
same time - javascript is single threaded. About half the time, the
one set for a 20ms interval will call the function twice between calls
from the one set for a 30ms interval. Other times it will call once.

The delay between calls will, in theory, be one of 20ms, 10ms or 0ms.
The delay in practice might be much longer and more unevenly spaced
depending on a variety of factors beyond the script programmer's
control or knowledge. Issues resulting from that may or may not be
significant.


--
Rob

On Jan 31, 7:28 pm, RobG <rg... (AT) iinet (DOT) net.au> wrote:

On Feb 1, 1:07 pm, timothytoe <timothy... (AT) gmail (DOT) com> wrote:

On Jan 31, 5:17 pm, Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> wrote:

Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> writes:
And that's disregarding the fact
that you're displaying *each frame* for *every* call to run()

Never mind, I misread your code.

It still doesn't make any sense, though.

Comments added.

/** @protected - for internal use.
* Calls _playFrame() on each anim.
* This object is for internal use, tightly coupled to Animation.
*/
APE.anim.Manager = new function() {

/**
* doubleThreaded animations exhibit varying
* degrees of improvement on performance, depending on the browser.
* Particularly, any version of Safari on Mac or Windows, and
* Internet Explorer on Win9.x
* Set this flag to false to reduce CPU hogging.
*/
this.isDoubleThreaded = true;

/**
* @private - keeps track of activeAnimations in main loop.
*/
var activeAnimations = [];

/**
* @private - thread timers.
*/
var intervalId, intervalId2;

/**
* Registers the animation in the thread pool once.
* @param {Animation} anim the animation to register.
*/
this.register = function(anim) {
if(activeAnimations.length === 0)
start();
for(var i = 0; i < activeAnimations.length; i++) {
if(activeAnimations[i] === anim) {
return;
}
}
activeAnimations.push(anim);
};

/**
* Registers the animation in the thread pool once.
* @param {Animation} anim the animation to register.
*/
this.unregister = function(anim) {
for(var i = 0; i < activeAnimations.length; i++) {
if(activeAnimations[i] === anim) {

activeAnimations.splice(i, 1);
}
}
if(activeAnimations.length == 0) {
activeAnimations = [];
stop();
}
};

this.toString = function() {
return"APE anim.Manager";
};

/**
* starts run();
* @private
*/
function start() {
// Double threaded.
intervalId = window.setInterval(run, 20);
if(this.isDoubleThreaded)
this.intervalId2 = window.setInterval(run, 30);
}

/**
* Plays the frame for each animation.
* @private - starts run().
*/
function run() {
// Check animations.legth each iteration. Some animations
// finish before others and must be unregistered.
for(var i = 0; i < activeAnimations.length; i++)
activeAnimations[i]._playFrame();
}

/**
* Called automatically when there are no more activeAnimations to
run.
*/
function stop() {
window.clearInterval(intervalId);
window.clearInterval(intervalId2);
}
};

Joost.

Are you saying time-based animation doesn't make sense? There are a
LOT of videogames out there that work that way.

No, he's not. But setting two setIntervals in motion that both call
the same function may well have unexpected results. Contrary to the
"two thread" inference, the two will never call the function at the
same time - javascript is single threaded. About half the time, the
one set for a 20ms interval will call the function twice between calls
from the one set for a 30ms interval. Other times it will call once.

The delay between calls will, in theory, be one of 20ms, 10ms or 0ms.
The delay in practice might be much longer and more unevenly spaced
depending on a variety of factors beyond the script programmer's
control or knowledge. Issues resulting from that may or may not be
significant.

That's the problem. It's a crapshoot. It's mostly Firefox is so

choppy. And if I have more stuff on the page, such as drag drop during
an animation, or if the user's CPUs are maxed (like if they're running
GMail or Yahoo Mail, or Google Maps or some other heavy app in another
tab), then it would hog the CPU too much, I think.

But there's no "available cpus" or yeild() or thread.priority or
anything. Should I double thread (double setTimeout), or not?

Garrett

--
Rob

dhtml <dhtmlkitchen (AT) gmail (DOT) com> writes:

On Jan 31, 7:28 pm, RobG <rg... (AT) iinet (DOT) net.au> wrote:
On Feb 1, 1:07 pm, timothytoe <timothy... (AT) gmail (DOT) com> wrote:

No, he's not. But setting two setIntervals in motion that both call
the same function may well have unexpected results. Contrary to the
"two thread" inference, the two will never call the function at the
same time - javascript is single threaded. About half the time, the
one set for a 20ms interval will call the function twice between calls
from the one set for a 30ms interval. Other times it will call once.

The delay between calls will, in theory, be one of 20ms, 10ms or 0ms.
The delay in practice might be much longer and more unevenly spaced
depending on a variety of factors beyond the script programmer's
control or knowledge. Issues resulting from that may or may not be
significant.

That's more or less what I meant, yes.

That's the problem. It's a crapshoot.

No, it will only "work" (or do whatever you think it should do) by
accident, some of the time. The rest of the time it won't.

It's mostly Firefox is so choppy.

Choppy is the expected behaviour when you've got two interfering
intervals flipping though the frames.

But there's no "available cpus" or yeild() or thread.priority or
anything.

That's because javascript is always single-threaded. Whatever you think
this does, it's probably wrong.

Should I double thread (double setTimeout), or not?

What I meant with it not making sense is that I can't think of any
reason why you would think your "double-threaded" strategy would *ever*
do anything but mess things up.

I understand the code just fine. What I don't understand is why you
think the "double-threaded" strategy would be helpful in any way.

Joost

dhtml wrote:

On Jan 31, 1:27 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:
On Feb 1, 12:14 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
Also, what about double threading for animations? Is it too much of
a CPU hog to start setInterval twice for one run() method?
Probably not. What is important is that the intervals do not get too
short and that they do not overlap for changing the same property.
Which is why window.setTimeout() should be used in favor of
window.setInterval() in animations.

I'm using time-based animation.

Pardon? Is there any other sort of animation?

Distance is calculated on a rationalValue (or floating point position
[0-1]). The "property" is always a number from [0-1]. In a 2 sec
animation, if 1 sec had elapsed, then the position would be 0.5.

It matters not how far the object is moved but how many steps the motion
takes. The more steps, the shorter each interval, the more calls are to be
performed, the greater is the CPU load, and the more likely is that your
animation does not run smoothly because either your timers accumulate or the
layout engine cannot handle it anymore. Accumulation is more likely when
you use window.setInterval() instead of window.setTimeout(). I have
explained why a few months ago; search the newsgroup.

window.setInterval(run, 20); if(this.isDoubleThreaded) this.intervalId2 =
window.setInterval(run, 30); }

This is not going to work properly. Consider the timeline here
(`*' denotes a call):

intv1 * * * * * *
intv2 | * | * | * | *
steps | | | | | | | |

----+----+----+----+----+----+----+----+----+----+----+----+----
0 10 20 30 40 50 60 70 80 90 100 110 120 ms

Meaning that every 60 ms (60 is the LCM of 20 and 30) the scheduler will
have to handle two calls. Since that is not going to happen as the
implementation is single-threaded indeed, the second call will be slightly
delayed. Nevertheless, at almost the same time you do the animation, moving
the object virtually twice per each step. Also note that the second
window.setInterval() call happens shortly after the first one, and not
simultaneously, and that 10 ms is the minimum timeout that Mozilla on x86
will handle. So the delay that can be expected on interval is increased by
at least that time span (consider external interference). A "jumping"
animation in place of a smooth one becomes more and more likely:

intv1 * * * * * *
intv2 | * | | * | * | | *
steps | | | | | | | | | |

----+----+----+----+----+----+----+----+----+----+----+----+----
0 10 20 30 40 50 60 70 80 90 100 110 120 ms

HTH

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

On Feb 1, 11:18 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

dhtml wrote:
On Jan 31, 1:27 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:
On Feb 1, 12:14 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
Also, what about double threading for animations? Is it too much of
a CPU hog to start setInterval twice for one run() method?
Probably not. What is important is that the intervals do not get too
short and that they do not overlap for changing the same property.
Which is why window.setTimeout() should be used in favor of
window.setInterval() in animations.

I'm using time-based animation.

Pardon? Is there any other sort of animation?

The other kind is frame-based.

you have distance and time and number of frames.

setInterval(f, 20) the function f doesn't fire every 20 ms. It depends
how long f takes, among other things, before f can fire again.

If distance-per-frame is a constant, then total time will increase,
making the animation time vary greatly between browsers. This is frame-
based animation.

I check the time in each call to _playFrame(). Distance is calculated
as a result of elapsed/total. distance = [0-1]. distance is elapsed =
new Date-startTime; distance = elapsed/totalTime. That's time based.
The animation finishes in a certain time. It can go over totalTime,
but not by a large amount; maybe 10-20ms at most. When that happens,
the animation is ended with distance = 1. In Time based animation, the
number of frames varies. But if there's double threads, the frame rate
increases. In webkit and IE, the animation is super smooth with the
doubled frame rate. Webkit is fine with up to 5 timers (setInterval),
actually.

Distance is calculated on a rationalValue (or floating point position
[0-1]). The "property" is always a number from [0-1]. In a 2 sec
animation, if 1 sec had elapsed, then the position would be 0.5.

It matters not how far the object is moved but how many steps the motion
takes. The more steps, the shorter each interval, the more calls are to be
performed, the greater is the CPU load, and the more likely is that your
animation does not run smoothly because either your timers accumulate or the
layout engine cannot handle it anymore. Accumulation is more likely when
you use window.setInterval() instead of window.setTimeout(). I have
explained why a few months ago; search the newsgroup.

The search feature on Google Groups does not work at all in any
browser for any Google username on this computer; I think it has to do
with a language preference cookie somewhere. Even when I click
"without the language restriction" link, it returns 0 results.

window.setInterval(run, 20); if(this.isDoubleThreaded) this.intervalId2 =
window.setInterval(run, 30); }

This is not going to work properly. Consider the timeline here
(`*' denotes a call):

intv1 * * * * * *
intv2 | * | * | * | *
steps | | | | | | | |
|----+----+----+----+----+----+----+----+----+----+----+----+----
0 10 20 30 40 50 60 70 80 90 100 110 120 ms

Meaning that every 60 ms (60 is the LCM of 20 and 30) the scheduler will
have to handle two calls. Since that is not going to happen as the
implementation is single-threaded indeed, the second call will be slightly
delayed. Nevertheless, at almost the same time you do the animation, moving
the object virtually twice per each step. Also note that the second
window.setInterval() call happens shortly after the first one, and not
simultaneously, and that 10 ms is the minimum timeout that Mozilla on x86
will handle. So the delay that can be expected on interval is increased by
at least that time span (consider external interference). A "jumping"
animation in place of a smooth one becomes more and more likely:

intv1 * * * * * *
intv2 | * | | * | * | | *
steps | | | | | | | | | |
|----+----+----+----+----+----+----+----+----+----+----+----+----
0 10 20 30 40 50 60 70 80 90 100 110 120 ms

The jumping I get i caused by mozilla being a CPU hog for whatever

else it's doing. Adding more timers hogs more CPUs, which contributes
to jumpiness in a different way.

If I change the second timer so they're both 20ms. I don't know if
that means the other time will have to "yeild" less or not. It could
be that the timers have to compete instead of weave and that's not
determinable. Even if the LCM was high (lets say I picked 45 for the
second setInterval, LCM would be 180); well, I still get jerky
behavior. Even with only 1 timer. It's mozilla.

HTH

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

dhtml wrote:

On Feb 1, 11:18 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
dhtml wrote:
On Jan 31, 1:27 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:
On Feb 1, 12:14 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
Also, what about double threading for animations? Is it too
much of a CPU hog to start setInterval twice for one run()
method?
Probably not. What is important is that the intervals do not get
too short and that they do not overlap for changing the same
property. Which is why window.setTimeout() should be used in
favor of window.setInterval() in animations.
I'm using time-based animation.
Pardon? Is there any other sort of animation?

The other kind is frame-based. you have distance and time and number of
frames.

I see. The time reference confused me because timing is involved in any
animation (delta(x) := t / frames). Time-based animation, as you call it,
is the only sensible thing to do on the Web as you can't do moves shorter
than 1px.

setInterval(f, 20) the function f doesn't fire every 20 ms. It depends
how long f takes, among other things, before f can fire again.

Yes, I have said that.

If distance-per-frame is a constant, then total time will increase,
making the animation time vary greatly between browsers.

And operating systems. And platforms. It is mostly the system timer tick
interval that determines the minimum time resolution that can be achieved in
a scripted animation.

This is frame-based animation.

ISTM you are applying terms on this situation that don't fit.

I check the time in each call to _playFrame(). Distance is calculated as
a result of elapsed/total. distance = [0-1].

Since you can't measure the elapsed time exactly, that approach is doomed to
fail.

[...] Accumulation is more likely when you use window.setInterval()
instead of window.setTimeout(). I have explained why a few months ago;
search the newsgroup.

The search feature on Google Groups does not work at all in any browser
for any Google username on this computer; I think it has to do with a
language preference cookie somewhere. Even when I click "without the
language restriction" link, it returns 0 results.

I doubt that. Try this:

http://groups.google.com/groups?q=se...ing=d&filter=0

Nevertheless, Google Groups is flawed enough not to find my article directly
(Message-ID: <46EF029E.6050508 (AT) PointedEars (DOT) de>, Date:
2007-09-18T00:41:34+02:00, Subject "Re: Need help with textboxes") via a
regular search. The following, found with a subject-only search, should work:

http://groups.google.com/group/comp....1?dmode=source

The jumping I get i caused by mozilla being a CPU hog for whatever else
it's doing. Adding more timers hogs more CPUs, which contributes to
jumpiness in a different way.

Your observation is correct, however your conclusion is not.

If I change the second timer so they're both 20ms. I don't know if that
means the other time will have to "yeild" less or not. It could be that
the timers have to compete instead of weave and that's not determinable.
Even if the LCM was high (lets say I picked 45 for the second
setInterval, LCM would be 180); well, I still get jerky behavior.

The value of the LCM of the interval lengths does not matter; as long as it
is greater than 1 you will have problems. The logical conclusion is not to
let scripts do the same thing in different intervals.

Even with only 1 timer. It's mozilla.

It is your concept that is erroneous. Use window.setTimeout() instead.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

On Feb 2, 3:25 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

dhtml wrote:
On Feb 1, 11:18 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
dhtml wrote:
On Jan 31, 1:27 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:
On Feb 1, 12:14 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
Also, what about double threading for animations? Is it too
much of a CPU hog to start setInterval twice for one run()
method?
Probably not. What is important is that the intervals do not get
too short and that they do not overlap for changing the same
property. Which is why window.setTimeout() should be used in
favor of window.setInterval() in animations.
I'm using time-based animation.
Pardon? Is there any other sort of animation?

The other kind is frame-based. you have distance and time and number of
frames.

I see. The time reference confused me because timing is involved in any
animation (delta(x) := t / frames). Time-based animation, as you call it,
is the only sensible thing to do on the Web as you can't do moves shorter
than 1px.

setInterval(f, 20) the function f doesn't fire every 20 ms. It depends
how long f takes, among other things, before f can fire again.

Yes, I have said that.

If distance-per-frame is a constant, then total time will increase,
making the animation time vary greatly between browsers.

And operating systems. And platforms. It is mostly the system timer tick
interval that determines the minimum time resolution that can be achieved in
a scripted animation.

This is frame-based animation.

ISTM you are applying terms on this situation that don't fit.

I check the time in each call to _playFrame(). Distance is calculated as
a result of elapsed/total. distance = [0-1].

Since you can't measure the elapsed time exactly, that approach is doomed to
fail.

[...] Accumulation is more likely when you use window.setInterval()
instead of window.setTimeout(). I have explained why a few months ago;
search the newsgroup.

The search feature on Google Groups does not work at all in any browser
for any Google username on this computer; I think it has to do with a
language preference cookie somewhere. Even when I click "without the
language restriction" link, it returns 0 results.

I doubt that. Try this:

http://groups.google.com/groups?q=se...3APointedEars%...

Groups search does not work on Google Wifi. I have narrowed it down to

that. It may work on some other networks, but not Google wifi.

That link above returns 0 Resutls.

Nevertheless, Google Groups is flawed enough not to find my article directly
(Message-ID: <46EF029E.6050... (AT) PointedEars (DOT) de>, Date:
2007-09-18T00:41:34+02:00, Subject "Re: Need help with textboxes") via a
regular search. The following, found with a subject-only search, should work:

http://groups.google.com/group/comp..../491749a08ef7c...

That's actually good info.

with setInterval, you get the timer whenever. It's supposed to be
nMillis after callbackFn.

setInterval(callbackFn, 20);

means call callbackFn, wait 20, do it again.

What I found is that w/2 timeouts, the browser will invoke them at the
same time. It doesn't matter when you start the second.

setInterval(bla, 100);
setTimeout(function() { setInterval(bla, 100); }, 50);

They callbacks get executed, but all at the same time.

I didn't write a formal test; I found that if I try to check the
elapsed time and print that to an element:
el.innerHTML += ( new Date- this.startTime );

Tje timers would result in like:

50
50
100
100
150
150
150
200
....

Mozilla bunched them up more closely w/2 timers.

It is your concept that is erroneous. Use window.setTimeout() instead.

I might reconsider recursive setTimeout.

http://ejohn.org/blog/analyzing-timer-performance/

I see more fluctuation with setInterval.

Less fluctuation with 1 timer.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee