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

Reply via email to