- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Thu, 20 Aug 2015 09:14:40 +1200
- To: Ian Vollick <vollick@chromium.org>
- Cc: Justin Novosad <junov@google.com>, WHATWG <whatwg@whatwg.org>, Rick Byers <rbyers@chromium.org>
On Thu, Aug 20, 2015 at 4:21 AM, Ian Vollick <vollick@chromium.org> wrote: > On Wed, Aug 19, 2015 at 7:36 AM Justin Novosad <junov@google.com> wrote: > >> On Wed, Aug 19, 2015 at 10:13 AM, Rick Byers <rbyers@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
Received on Wednesday, 19 August 2015 21:15:09 UTC