Define algorithm for determining whether high priority work exists.

[rmcilroy]

Addresses #86 and #87.

[rmcilroy]

@rniwa, @yoavweiss, PTAL, thanks.

[rmcilroy]

@rniwa could you have a look please. Does this address the issues you had?

[rniwa]

Note the PR as it stands excludes any task enqueued that's not of user interaction source because the current wording is that "If the user [agent ]determines that it has internal high-priority work pending, then return true", thereby excluding any tasks that have already been enqueued.

It might be better to simply say that "[i]f the user agent dependent mechanism determines that there is a higher priority work than executing idle callbacks, return true".

[rmcilroy]

Note the PR as it stands excludes any task enqueued that's not of user interaction source

Yes that is intentional. The intention is to only reset the deadline if there is user input task pending (with a similar algorithm to the is-input-pending proposal). The idle task won't start if there are any other task pending (since it's queued on the lowest priority idle task queue), but once it's started we only want it to yield earlier than its original deadline if really high priority (e.g., user input) events occur.

[rniwa]

How about rAF? Shouldn't we yielding once the rendering opportunity arrives?

[rmcilroy]

That should already be taken into account when computing the deadline initially.

[rniwa]

That should already be taken into account when computing the deadline initially.

As I have stated previously, this is not possible in WebKit. We can't precisely determine when a rendering opportunity would occur. Given this, it seems prudent that this definition will take that into account.

[rmcilroy]

I thought we agreed during the call that WebKit could do a similar estimation as we do in Chrome? In our case the renderer process also doesn't control rAF trigger, the browser process signals it to us. We estimate next rAF based on current frame intervals. In the notes it's recorded as this:

Ryosuke: ... we can’t query raF, that’s owned by core animation Ross: we kinda have similar problem, we rely on browser process to tell us … we know what is expected, we speculate based on frame frequency Ryosuke: we can also do that, I guess

Either way, it is important that the initial deadline takes rAF into account as this is one of the main use-cases of rIC (enabling the JS devs to estimate how much time they have to do work before the next frame is scheduled.

[rniwa]

I thought we agreed during the call that WebKit could do a similar estimation as we do in Chrome?

I never agreed to do anything. Only thing I said is that we could do something like that, not that we're going to do it or that it's something we want to implement. Furthermore, because of the way things are architected, such an estimate would be very much inaccurate in WebKit even if we were to implement such an estimate.

Either way, it is important that the initial deadline takes rAF into account as this is one of the main use-cases of rIC (enabling the JS devs to estimate how much time they have to do work before the next frame is scheduled.

Well, an estimation is one thing. Knowing it has come is another. There is no reason rIC can't yield once the rendering opportunity has occurred to a document.

[rmcilroy]

I never agreed to do anything. Only thing I said is that we could do something like that, not that we're going to do it or that it's something we want to implement.

I was not trying to imply that you'd agreed to implementing this in Webkit, merely that we had discussed it as being possible - apologies if it came across that way.

Well, an estimation is one thing. Knowing it has come is another. There is no reason rIC can't yield once the rendering opportunity has occurred to a document.

We can certainly add an item checking if there is a rendering opportunity here (I'll add it to the PR), but this should only really trigger in infrequent cases where something happened that we couldn't predict at deadline calculation time (e.g., frame rate changed or JS triggered a rendering opportunity we didn't know about before).

The initial deadline should have baked in an estimate of when the next rendering opportunity is likely to start so that it can be used by the rIC callback user-code to make an ahead-of-time decision of whether to start long-running work or wait for a future idle period that might have a longer deadline available.

[rmcilroy]

Comments should be addressed, please take another look @rniwa

[rmcilroy]

Are we good to land this?

[yoavweiss]

@rniwa - friendly ping! :)

[rmcilroy]

@annevk could you please review this PR? Unfortunately Ryosuke doesn't have bandwidth to do this review right now.

[yoavweiss]

Obsoleted by #95