On Mar 2, 2013 6:32 AM, Florian Bösch pya...@gmail.com wrote:
You can also wrap your own requestAnimationFrameInterval like so:
var requestAnimationFrameInterval = function(callback){
var runner = function(){
callback();
requestAnimationFrame(runner);
};
runner
requestAnimationFrameInterval like so:
var requestAnimationFrameInterval = function(callback){
var runner = function(){
callback();
requestAnimationFrame(runner);
};
runner();
}
This will still stop if there's an exception thrown by callback, but it
lets you write a cleaner
Hi,
If someone wants to reuse the same function for
requestionAnimationFrame, he/she has to go through:
requestAnimationFrame(function f(){
requestAnimationFrame(f);
// do stuff
})
I was wondering why it was the case. Other event-like mechanism do not
require to re
,
he/she has to go through:
requestAnimationFrame(function f(){
requestAnimationFrame(f);
// do stuff
})
I was wondering why it was the case. Other event-like mechanism do not
require to re-subscribe after an event happened.
Thanks,
David
On 3/2/13 6:03 AM, David Bruant wrote:
I was wondering why it was the case. Other event-like mechanism do not
require to re-subscribe after an event happened.
requestAnimationFrame was designed as a way for web pages to do
animations without hogging CPU like they did with setTimeout
your followup requestAnimationFrame call at
the very beginning of the callback function and it will work fine too.
On Sat, Mar 2, 2013 at 5:03 AM, David Bruant bruan...@gmail.com wrote:
If someone wants to reuse the same function for requestionAnimationFrame,
he/she has to go through:
requestAnimationFrame(function f(){
requestAnimationFrame(f);
// do stuff
})
FYI, this pattern
You can also wrap your own requestAnimationFrameInterval like so:
var requestAnimationFrameInterval = function(callback){
var runner = function(){
callback();
requestAnimationFrame(runner);
};
runner();
}
This will still stop if there's an exception thrown by callback, but it
lets
FYI, the Web Performance WG [WebPerf] intends to add Visibility API,
Yield and Continue, requestAnimationFrame to their Charter when it is
renewed/updated (in the next month or two):
See their recent meeting minutes for some details:
http://www.w3.org/2011/02/23-webperf-minutes.html#item01
):
following in the footsteps of a previous thread
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0223.html
I'd like to see if there is some consensus on this issue. Various people
are anxious to see this happen in more browsers.
A couple of questions came up for requestAnimationFrame
How about this way of looking at it
Goals
1) prevent programmer error
2) provide a good user experience (browser is responsive with lots of tabs)
The solution to #1 as currently proposed is to guarantee that
requestAnimationFrame will have it's callback called periodically, even if
it's
On Wed, Nov 24, 2010 at 12:08 PM, Gregg Tavares (wrk) g...@google.comwrote:
requestAnimationFrame though is generally designed to be used for updating
a canvas (2d or 3d) which will likely be heavy both in terms of CPU usage
(drawing lots of lines/curves/images into the canvas) and in terms
* Robert O'Callahan wrote:
Couldn't is never an issue here. You can always use setTimeout as a
backstop to ensure that your end-of-animation code runs even if
requestAnimationFrame never fires a callback. My concern is that authors are
likely to forget to do this even if they need to, because
How about just running the callback once the tab becomes visible again? It
will run, but just not unless there is reason to animate/paint.
-Darin
On Thu, Nov 18, 2010 at 6:08 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
I suppose we could have a variant API that explicitly means I don't
* Ojan Vafai wrote:
On Fri, Nov 19, 2010 at 2:54 PM, Cameron McCormack c...@mcc.id.au wrote:
Darin Fisher:
I can imagine a situation where you have an animation that goes for,
say, 10 seconds, and once the animation finishes something else happens.
The 1 second maximum period seems useful in
* Robert O'Callahan wrote:
Those are good goals, except I think we need to drill down into (c). Are
people changing stuff at 15Hz for crude performance tuning, or for some
other reason?
There are many kinds of animations where you cannot easily interpolate
between frames, so drawing in Ones
is in the background, and implement the logic as you see fit.
Couldn't is never an issue here. You can always use setTimeout as a
backstop to ensure that your end-of-animation code runs even if
requestAnimationFrame never fires a callback. My concern is that authors are
likely to forget to do
, especially on netbooks. As it is, only 1-3 areas are ever visible at
once.
Yeah, that makes sense.
Then I suggest adding requestAnimationFrame to elements, so you can call
element.requestAnimationFrame(callback).
I think there needs to be a guarantee that the callback is eventually called
even
re-rendering their ads all the time I suspect that page would get pretty
slow, especially on netbooks. As it is, only 1-3 areas are ever visible at
once.
Yeah, that makes sense.
Then I suggest adding requestAnimationFrame to elements, so you can call
element.requestAnimationFrame(callback
requestAnimationFrame to elements, so you can call
element.requestAnimationFrame(callback).
I think there needs to be a guarantee that the callback is eventually
called even if the element never becomes visible. People sometimes want to
take action when an animation finishes
On Fri, Nov 19, 2010 at 8:21 AM, Gregg Tavares (wrk) g...@google.comwrote:
On Thu, Nov 18, 2010 at 12:45 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
I think there needs to be a guarantee that the callback is eventually
called even if the element never becomes visible. People sometimes
On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher da...@chromium.org wrote:
I agree. What's the use case for animating hidden tabs (or canvases that
are hidden)?
One of the big problems with JavaScript based animations is that they have
no way of knowing they should go idle when their window
On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher da...@chromium.org wrote:
I agree. What's the use case for animating hidden tabs (or canvases that
are hidden)?
One of the big problems with JavaScript based
On Thu, Nov 18, 2010 at 1:54 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher da...@chromium.orgwrote:
I agree. What's the use case for animating hidden tabs (or
, and
will continue to do so no matter what we do, I think rather than trying to
make requestAnimationFrame more efficient at the expense of making it
error-prone, it would be better for implementors to come up with more
general solutions to the busy background tab problem. For example, a
browser could
I suppose we could have a variant API that explicitly means I don't care if
the callback never gets called. I don't know what to call it, though.
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the
a bit. But we'll still try to meet it on a
best-effort basis --- i.e. we'll run the JS animations once per composited
frame, if the JS can keep up.
So you're saying that there's no guarantee that requestAnimationFrame will
actually keep things in sync?
Right. A cast-iron guarantee
that requestAnimationFrame
will actually keep things in sync?
Right. A cast-iron guarantee that requestAnimationFrame callbacks will run
to completion before painting is incompatible with the goal of being able to
repaint the browser window even if scripts are running too long or
completely hung.
But we *can
On Thu, Nov 18, 2010 at 11:30 AM, Cameron McCormack c...@mcc.id.au wrote:
Incidentally, I wonder if the beforepaint/animationTick event could be
dropped altogether. Why isn’t just the callback sufficient?
For animation, it is sufficient. We should drop the beforePaint event from
the spec for
On Thu, Nov 18, 2010 at 11:22 AM, Gregg Tavares (wrk) g...@google.comwrote:
Think about this some more. the point if the previous suggestion is
that updating keeping a JS animation in sync with a CSS animation has
nothing to do with painting or rendering. The fact that apparently firefox
On 11/17/10 5:22 PM, Gregg Tavares (wrk) wrote:
Think about this some more. the point if the previous suggestion is
that updating keeping a JS animation in sync with a CSS animation has
nothing to do with painting or rendering. The fact that apparently
firefox ties those 2 things together is
On Wed, Nov 17, 2010 at 6:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/17/10 5:22 PM, Gregg Tavares (wrk) wrote:
Think about this some more. the point if the previous suggestion is
that updating keeping a JS animation in sync with a CSS animation has
nothing to do with painting or
On Wed, Nov 17, 2010 at 5:20 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Nov 18, 2010 at 11:22 AM, Gregg Tavares (wrk) g...@google.comwrote:
Think about this some more. the point if the previous suggestion is
that updating keeping a JS animation in sync with a CSS animation
On 11/17/10 9:48 PM, James Robinson wrote:
In Safari (and at some point in Chrome as well) declarative animations
are not necessarily sampled in the main thread.
Right, that's the direction Robert mentioned Gecko is headed as well.
I'm not entirely convinced about how important it is to
, if the JS can keep up.
So you're saying that there's no guarantee that requestAnimationFrame will
actually keep things in sync?
When an element becomes visible, does its timer fire immediately if the
last firing was more than 'interval' ago?
Yes? No? Does it matter? What happens now?
I
it on a
best-effort basis --- i.e. we'll run the JS animations once per composited
frame, if the JS can keep up.
So you're saying that there's no guarantee that requestAnimationFrame will
actually keep things in sync?
Right; if the browser is trying to paint animation frames every 20ms,
and two
basis --- i.e. we'll run the JS animations once
per composited frame, if the JS can keep up.
So you're saying that there's no guarantee that requestAnimationFrame
will actually keep things in sync?
The guarantees we currently supply are:
1) Your requestAnimationFrame handler will be called
the JS animations once per composited
frame, if the JS can keep up.
So you're saying that there's no guarantee that requestAnimationFrame will
actually keep things in sync?
Right. A cast-iron guarantee that requestAnimationFrame callbacks will run
to completion before painting is incompatible
for requestAnimationFrame
(see
http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html)
One is, how should this api be used if I want an app to update at 10hz. It
seems to be designed to assume I want the maximum frame rate. If I want to
run slower would I just use
setInterval(function
requestAnimationFrame and beforePaint to be window level apis.
Note that the beforePaint event can make arbitrary changes to the DOM
(and in particular can change whether things are visible)...
1) All of them will get a beforePaint event even if most or all of them
are scrolled off the visible area
canvases
redrawn if they are not on the screen but the current design has
requestAnimationFrame and beforePaint to be window level apis.
Note that the beforePaint event can make arbitrary changes to the DOM (and
in particular can change whether things are visible)...
1) All of them will get
On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) g...@google.comwrote:
One is, how should this api be used if I want an app to update at 10hz. It
seems to be designed to assume I want the maximum frame rate. If I want to
run slower would I just use
setInterval(function() {
On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) g...@google.comwrote:
I've seen proposals for something more like
element.setInternvalIfVisible(func, internval);
Which is the same as setInterval but only gets called if the element is
visible. With that kind of API there is no
a interval to be passed to
requestAnimationFrame when a callback is specified. When such an
interval is passed, the implementation would call the callback no
sooner than the requested interval.
Though one concern would be that people might depend on the callback
being called exactly
On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) g...@google.comwrote:
One is, how should this api be used if I want an app to update at 10hz.
It seems to be designed to assume I want the maximum frame rate.
On Mon, Nov 15, 2010 at 4:07 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) g...@google.comwrote:
I've seen proposals for something more like
element.setInternvalIfVisible(func, internval);
Which is the same as setInterval but
On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Gregg Tavares (wrk) wrote:
There is plenty of flash content that has a lower than 60hz (or fast as
possible) refresh rate. When something is instead implementing in HTML5
instead of Flash what should they do to get the
On Mon, Nov 15, 2010 at 5:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
* Gregg Tavares (wrk) wrote:
There is plenty of flash content that has a lower than 60hz (or fast as
possible) refresh rate. When something is
* Jonas Sicking wrote:
On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The frame rate is a number in the swf header that cannot be set to a as
fast as possible value.
Ah, so that also means that different animations can't run with
different frame rates?
That's the
involved can be encoded in the callback function passed to
requestAnimationFrame, as above.
I've seen proposals for something more like
element.setInternvalIfVisible(func, internval);
Which is the same as setInterval but only gets called if the element is
visible.
Right, but the point
On 11/15/10 7:45 PM, Gregg Tavares (wrk) wrote:
Does it matter? What happens now? Now, with setInterval there is no
connection to rendering. I set the code to update one element to have an
interval of 16 and another to have an interval of 100. If the first one
makes the second one visible that
On Tue, Nov 16, 2010 at 1:26 PM, Gregg Tavares (wrk) g...@google.comwrote:
On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
If you really want to animate in 10Hz steps, then I suggest you do
something like
var start = window.animationTime;
var rate = 10; // Hz
, if the JS can keep up.
When an element becomes visible, does its timer fire immediately if the
last firing was more than 'interval' ago?
Yes? No? Does it matter? What happens now?
I suspect it would matter for interop, yes. Again, with
requestAnimationFrame the question does not arise.
I'm
On Mon, Nov 15, 2010 at 6:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/15/10 6:55 PM, Gregg Tavares (wrk) wrote:
How would setInterval with multiple functions on
mozRequestAnimationFrame solve this issue? They are still all going to
get called at the fastest interval right?
Why?
54 matches
Mail list logo
