Re: [whatwg/streams] [Question] questions about streaming-element-backpressure.js (#855)

@abdulhannanali You are right, I am abusing `requestAnimationFrame` to get an approximate idea of when the browser is ready to receive more HTML without janking. It's unfortunate this is confusing. I was trying to create a simple example of using backpressure to avoid jank. Because each chunk of the table takes longer to layout that the previous one, using a fixed chunk size and delay gave very poor results.

I experienced the issue with the chunk size become incredibly small during my tests, which is why I put in this hack:
https://github.com/whatwg/streams/blob/99ffba7a632c261566c12da60bb35800a42e3b3f/demos/tags/streaming-element-backpressure.js#L90
to keep the chunk size at 256 or larger.

`MS_PER_FRAME`, the minimum chunk size and `FRAMES_TO_SMOOTH_OVER` are all hacks to make it possible to do this with a very simple algorithm.

`startNewChunk` doesn't reset a timer explicitly, but it does implicitly reset the "frame timer" by changing how long the following call to `startNewChunk` will take.

The fundamental issue is that the browser doesn't provide an answer to the question "how much HTML can I render right now without causing jank?" So we have to use an approximation. It's certainly possible to create a far better approximation than this demo uses, but it would distract from the main point of the demo.

If you can find a way to make it easier to understand without making it longer or making the jank or load time worse, then please send a pull request. But don't worry too much about it.

---

Creating a span for each chunk is a cleaner method as it doesn't require strange hacks with iframes. However, it won't work if the chunks contain HTML tags because they can get split between spans. So the iframe hack is more general.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/855#issuecomment-347428584