Currently we just add all of the tile requests and expect the browser to download them.
If the user zooms we cannot cancel loading them etc.
We should use a queue instead so this can be handled nicer.
I will provide a pull request today. My motivations for implementing this were:
Limit the number of requests sent at once. Browsers prioritize javascript/json requests, so in my use cases the visual tiles did not get loaded until all the utfgrid tiles were loaded. When these take a non-trivial time to generate, this delays the visual tiles noticeably. Chrome/FF send at most 8 concurrent requests by default (not sure about IE), so I have set this to a (configurable) default of 4 concurrent utfgrid requests. This ensures that there is 4 available slots for image tiles;
Cancel loading requests. By limiting the number of concurrent requests, we can also ensure that if a tile has gone out of view before it even started loading then we can simply drop it from the queue. My implementation also cancels loading tiles after the ajax request was made. In Chrome, this works for JSON tiles but not JSON-P tiles. This provides an additional performance boost if the tile server detects dropped connections (not a trivial problem. I assume many won't; but the one I implemented for this project does if the connection gets dropped while in the server queue).
Currently we just add all of the tile requests and expect the browser to download them. If the user zooms we cannot cancel loading them etc. We should use a queue instead so this can be handled nicer.