W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: exposing CANVAS or something like it to Web Workers

From: James Robinson <jamesr@google.com>
Date: Mon, 14 May 2012 17:21:00 -0700
Message-ID: <CAD73mdJ2nWAXKnwCyCkQFjvPS90cO99PQYO5sN2a9YRMYxM3Fw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Mon, May 14, 2012 at 5:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/14/12 7:56 PM, Glenn Maynard wrote:
>> A tricky bit: you need to know which element to sync to, so the browser
>> knows which monitor's vsync to use.  According to [1] only WebKit's
>> requestAnimationFrame actually takes an element.  (That's surprising;
>> this seems obvious.
> Does WebKit actually use the element to determine vsync?  How do they
> handle cases when the element spans monitors?

> As far as I know WebKit's implementation uses the element to optimize out
> callbacks when the element is not visible, but that's it.

The element isn't used for anything currently in WebKit.  "Which vsync" is
determined by the monitor the tab/window/whatever lands on.  When this
spans monitors, something random happens (there aren't many good options).

> Note that Gecko, for example, does not tie requestAnimationFrame callbacks
> to vsync.  I can't speak for other UAs.

I think you'll want to.

- James

>  I mention this because
>> this method would need to accept a context in lieu of an element
> What would the context be used for?
> -Boris
Received on Tuesday, 15 May 2012 00:21:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC