Re: [w3ctag/design-reviews] Design Review: Prioritized Task Scheduling (big picture) (Issue #967)

Thanks for doing this work.  We see three general threads to this work, each of which are at a different stage, but all of which are worthwhile.
  
1. The work around basic task scheduling APIs, (`yield` and `wait` or whatever those end up being called).  This is good stuff.  We'd encourage you to take this to WHATWG and get that into their process now.  Aside from maybe that open naming issue, it is pretty solid.
  
2. The work around `render` and `requestAnimationFrame`, which deals with how the event loop interacts with the rendering process.  That seems less well formed, but still quite important, perhaps even more important than the first item.  Having a firm understanding of that interaction and clear means of controlling it would be a significant contribution to stability and performance of sites.  We'd encourage you to continue that work to understand that.  Please, don't feel constrained by how `requestAnimationFrame` is; if there are ways in which that could be improved and integrated into a more comprehensive scheduling system, that would be excellent.
  
3. A general set of hooks that other APIs might use for scheduling work on the main event loop.  To give an analogy, Fetch has an API for fetching stuff, but it also has a bunch of hooks that any other API can use if they need to obtain connections or resources.  That's a useful contribution here also.  For message channels or Fetch or WebRTC or whatever, the ability to schedule and prioritize work will be very useful.  That aspect too needs work, but that can be taken to WHATWG also.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/967#issuecomment-2342209958
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/967/2342209958@github.com>

Received on Tuesday, 10 September 2024 22:26:30 UTC