This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://fetch.spec.whatwg.org/#fetching [[ Every 50ms or whenever response's body's is pushed to, whichever is least frequent and as long as response has no termination reason and end-of-file has not been pushed, queue a task to process response body for response. ]] Why are we forcing there to be a 50ms lag here?
We have the 50ms so progress events go at about 60Hz iirc.
It is not 60Hz. That would require 16ms. The lag is there to prevent totally hanging the task queue, but I can't now recall where 50ms came from. (I think some other feature in the platform used 50ms, but which one..) Not having any limit was certainly an issue at some point. Also, the lag is just for progress events, except the last one, so it doesn't actually slow down loading the data or anything.
Discussion happened in July http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297279.html As Olli said, it affects only "progress" ProgressEvent dispatching. This revision changed the frequency to 50ms from 350ms. http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.43;r2=1.44;f=h http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0111.html Anne targeted 20fps. http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0312.html Olli agreed.
If progress events are intended to drive style changes, maybe they should be synced with requestAnimationFrame? (No opinion on targeting 60fps vs 20fps here.)
I've no problem with events being throttled. But that's not what this is doing. This is throttling doing anything at all with the data.
So I should queue plenty of tasks from Fetch and put the throttling in XMLHttpRequest. The idea here was to align all dependencies of Fetch as to having the same throttling behavior. But perhaps that's not the best strategy. (Note that the actual underlying stream is not delayed. It's just the higher level notification mechanism.) Okay?
I don't understand what you mean by "actual underlying stream" vs "higher level notification mechanism". I just mean the tasks that the "fetch" algorithm fires so that the data can be processed.
When the first task is run on the thread that invoked Fetch, that thread has access to response's body which is a stream. That stream is being pushed to whenever new data arrives. The other tasks being queued give some additional information mostly relevant for progress events. And then a task in the end to say everything is over.
I don't understand. How should this stream be used? Are you expecting the stream user to do an in-parallel algorithm that fires a task to handle each byte, rather than fetch doing it like it used to in the HTML spec?
It would go per chunk these days, not byte, but yeah, you're right, I should just put the throttling at a higher level.
https://github.com/whatwg/fetch/commit/d7e357d83380b50886832316c84ae125193b58b4