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

@ricea First of all sorry for the delay in replying, meanwhile I was learning about `requestAnimationFrame` whenever I found some time. 

Regarding the first one, the usage of `requestAnimationFrame` API seems a bit confusing in this application. The point of this api is to execute a set of statements that make changes to the pixels in some way before the next browser repaint, this will keep the animations in the browser synchronized and jank free giving us an abstraction to keep our application synchronized with the actual frame rate. However, it  seems to be the case that our usage of this API is entirely reverse of what was intended, do you think the following statements should move to the top 
https://github.com/whatwg/streams/blob/99ffba7a632c261566c12da60bb35800a42e3b3f/demos/tags/streaming-element-backpressure.js#L82-L84 right before we actually need to write the chunk to the iframe. https://github.com/whatwg/streams/blob/99ffba7a632c261566c12da60bb35800a42e3b3f/demos/tags/streaming-element-backpressure.js#L78

This would provide better result about the time it actually takes to execute the complete callback (and paint the result to the screen, not clear about this though).

`requestAnimationFrame` also seems to be providing a top level api, which can be significantly throttled down based on certain factors depending on the user agent such as the tab focus. In that case, would the logic we mention here still calculate appropriate number of chunks we want to write? Based on the wait time, it can even fall down to like 4 characters per frame, which will take some time to recover since there seems to be a limit of `3` for the frames to smooth over. 

-- 
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-347410198