n also wrap your own requestAnimationFrameInterval like so:
> >
> > var requestAnimationFrameInterval = function(callback){
> > var runner = function(){
> > callback();
> > requestAnimationFrame(runner);
> > };
> > runner();
> > }
>
On Mar 2, 2013 6:32 AM, "Florian Bösch" wrote:
>
> You can also wrap your own requestAnimationFrameInterval like so:
>
> var requestAnimationFrameInterval = function(callback){
> var runner = function(){
> callback();
> requestAnimationFrame(runner);
&g
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
On Sat, Mar 2, 2013 at 5:03 AM, David Bruant 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, th
at you can make your followup requestAnimationFrame call at
the very beginning of the callback function and it will work fine too.
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
e 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-subscribe after an event happened.
>
> Thanks,
>
> David
>
>
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
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
03 PM):
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 requestAnim
* 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
On Wed, Nov 24, 2010 at 12:08 PM, Gregg Tavares (wrk) wrote:
> 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
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&
en when the tab
> 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
* 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" r
* Ojan Vafai wrote:
>On Fri, Nov 19, 2010 at 2:54 PM, Cameron McCormack 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 this ca
On Fri, Nov 19, 2010 at 2:54 PM, Cameron McCormack wrote:
> Darin Fisher:
> > 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.
>
> I can imagine a situation where you have an animation that goes for,
Cameron McCormack:
> The 1 second maximum period seems useful in this case, because you might
> make the tab visible again for a long time, but you expect the
> “something else” to happen.
s/might/might not/, of course.
--
Cameron McCormack ≝ http://mcc.id.au/
Darin Fisher:
> 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.
I can imagine a situation where you have an animation that goes for,
say, 10 seconds, and once the animation finishes something else happens
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 wrote:
> I suppose we could have a variant API that explicitly means "I don't care
> if the call
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 Scri
ions use constant setTimeouts today, 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 backgrou
On Thu, Nov 18, 2010 at 1:54 PM, Robert O'Callahan wrote:
> On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan
> wrote:
>
>> On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher wrote:
>>
>>> I agree. What's the use case for animating hidden tabs (or canvases that
>>> are hidden)?
>>>
>>> One of the
On Fri, Nov 19, 2010 at 10:48 AM, Robert O'Callahan wrote:
> On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher 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
On Fri, Nov 19, 2010 at 10:46 AM, Darin Fisher 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 is hidden (in
On Fri, Nov 19, 2010 at 8:21 AM, Gregg Tavares (wrk) wrote:
> On Thu, Nov 18, 2010 at 12:45 AM, Robert O'Callahan
> wrote:
>
>> 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 a
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.requestAnimationF
een
>> and that would be a pretty good thing. If all 10 of those areas were
>> 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
me 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)".
I think the
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
synch
On Wed, Nov 17, 2010 at 5:20 PM, Robert O'Callahan wrote:
> On Thu, Nov 18, 2010 at 11:22 AM, 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 "pain
On Wed, Nov 17, 2010 at 6:27 PM, Boris Zbarsky 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 renderi
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 i
On Thu, Nov 18, 2010 at 11:22 AM, 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
On Thu, Nov 18, 2010 at 11:30 AM, Cameron McCormack 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 now.
Rob
-
eeded. (ie, don't render 60 frames a second if
> you're only changing stuff at 15)
Shouldn’t the name of the function be more general than
“setIntervalIfVisible”? We want the animations to tick slowly not just
when an object isn’t visible, but when it’s the best for the browser’s
overa
--- 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?
>
te compositor thread that
>>> guarantee has to be relaxed 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".
>>>
>>
>&g
t-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 g
n 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?
The guarantees we currently supply are:
1) Your requ
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 i
the JS on the beforePaint takes a while to complete what happens to
the browser? For example if you are resizing the browser? Is the browser
forced not to be able to actually paint until JS returns?
>
> Now, when animation is happening on a separate compositor thread that
> guarantee has
On Mon, Nov 15, 2010 at 6:17 PM, Boris Zbarsky 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?
>
> setInte
e animations.
Now, when animation is happening on a separate compositor thread that
guarantee has to be relaxed 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".
>
>> When
On Tue, Nov 16, 2010 at 1:26 PM, Gregg Tavares (wrk) wrote:
> On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan
> wrote:
>
>> If you really want to animate in 10Hz steps, then I suggest you do
>> something like
>> var start = window.animationTime;
>> var rate = 10; // Hz
>> var duration = 10; //
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 do
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 poi
* Jonas Sicking wrote:
>On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann 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 basic mode
On Mon, Nov 15, 2010 at 5:10 PM, Jonas Sicking wrote:
> On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann
> 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 HT
On Mon, Nov 15, 2010 at 5:01 PM, Bjoern Hoehrmann 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 similar resu
* 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 similar results? Checking
>cnn.com, time.com, arstechnica.com, wired.com an
On Mon, Nov 15, 2010 at 4:07 PM, Robert O'Callahan wrote:
> On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) wrote:
>
>> I've seen proposals for something more like
>>
>> element.setInternvalIfVisible(func, internval);
>>
>> Which is the same as setInterval but only gets called if the e
On Mon, Nov 15, 2010 at 3:58 PM, Robert O'Callahan wrote:
> On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) wrote:
>
>> 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 woul
curiosity, what are the use-cases for this?)
*If* this is a use case that is important enough to solve, then one
solution would be to allow 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
s
On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) wrote:
> 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 connection
On Tue, Nov 16, 2010 at 12:03 PM, Gregg Tavares (wrk) wrote:
> 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() {
>window.requestAnim
Canvas. Therefore
>> a site like cnn.com <http://cnn.com> or msnbc.com <http://msnbc.com> has
>>
>> 5 canvases running ads in each one. I don't really want all 5 canvases
>> redrawn if they are not on the screen but the current design has
>> requestAn
hey 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 a beforePaint event even
p 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(fun
59 matches
Mail list logo
