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. 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
