On 5/18/17 12:19 PM, Ben Kelly wrote:
On Wed, May 17, 2017 at 10:03 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
On 5/17/17 9:22 PM, Mark Hammond wrote:
I'm wondering if there are any ideas about how to solve this optimally?
I assume https://w3c.github.io/requestidlecallback/#the-requestidleca
llback-method doesn't have quite the right semantics here? That would
let you run when the browser is idle, and give you some idea of how long
you can run for before you should yield.
If rIC is not the right semantics, we could also set a time budget instead
of a magic flat limit. Every N operations call performance.now() and check
to see if the configured time exceeds the limit.
FWIW, we have a similar problem in the native TimeoutManager::RunTImeout()
method. I'm using a time budget approach to make it adapt to different
hardware better.
That sounds interesting and is almost certainly better than a hard-coded
50, but doesn't it have the same basic problem? That depending on what
other things are going on, the magic time-limit chosen will either be
too conservative (ie, sacrificing wall time) or too liberal (ie, still
causing jank)?
Thanks,
Mark.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
