On Wed, Aug 19, 2015 at 5:14 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick <voll...@chromium.org> wrote: > >> On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad <ju...@google.com> wrote: >> >>> On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers <rby...@chromium.org> >>> wrote: >>> >>>> Sounds great to me. I agree this is an important scenario. *Ian*, >>> >>> >>>> thoughts? >>> >>> >> I would certainly like to see requestAnimationFrame in a worker, but >> there is more risk of falling out of step with vsync in a vanilla worker >> that has access to APIs that are dangerous from a performance point of >> view. It would also be nice to run a worker with rAF on an elevated >> priority thread (or maybe even the compositor thread), but that would be a >> bad idea if it can do stuff like synchronous IO. >> > > I fear a proliferation of different kinds of restricted Workers that would > make it hard to handle multiple kinds of callbacks in a single Worker, so > I'd rather not introduce a new restricted kind unless it's absolutely > necessary. I think it would be fine to support rAF in a general > DedicatedWorker and then later, if absolutely necessary, provide an > elevated-priority Worker with restricted API. > > After implementing rAF for DedicatedWorker, the first slow-script > mitigation I'd like to introduce is the "you missed your frame deadline" > event that we've been talking about for a whlie. > In the requestIdleCallback proposal ( https://w3c.github.io/requestidlecallback/ ) a deadline argument is passed to the callback. That's an idea we could apply here as well. Not sure whether it is better or worse than using an event. > > Rob > -- > lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf > toD > selthor stor edna siewaoeodm or v sstvr esBa kbvted,t > rdsme,aoreseoouoto > o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea > lurpr > .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr > esn >
