Limit to only 10 image requests per page in ResourceScheduler.

content/browser/loader/resource_scheduler.h

Index: content/browser/loader/resource_scheduler.h
diff --git a/content/browser/loader/resource_scheduler.h b/content/browser/loader/resource_scheduler.h
index fa53c5b318f291d1d68a6054f4353d20958552b1..9f31af8cc7716d1fe6f66221f72e91e4effcd8bd 100644
--- a/content/browser/loader/resource_scheduler.h
+++ b/content/browser/loader/resource_scheduler.h
@@ -7,7 +7,6 @@
 
 #include <map>
 #include <set>
-#include <vector>
 
 #include "base/basictypes.h"
 #include "base/compiler_specific.h"
@@ -16,6 +15,7 @@
 #include "base/threading/non_thread_safe.h"
 #include "content/common/content_export.h"
 #include "content/public/browser/global_request_id.h"
+#include "net/base/priority_queue.h"
 
 namespace net {
 class URLRequest;
@@ -76,7 +76,7 @@ class CONTENT_EXPORT ResourceScheduler : public base::NonThreadSafe {
 
   typedef int64 ClientId;
   typedef std::map<ClientId, Client*> ClientMap;
-  typedef std::vector<ScheduledResourceRequest*> RequestQueue;
+  typedef net::PriorityQueue<ScheduledResourceRequest*> RequestQueue;
   typedef std::set<ScheduledResourceRequest*> RequestSet;
 
   struct Client {
@@ -94,9 +94,22 @@ class CONTENT_EXPORT ResourceScheduler : public base::NonThreadSafe {
   // Unthrottles the |request| and adds it to |client|.
   void StartRequest(ScheduledResourceRequest* request, Client* client);
 
-  // Calls StartRequest on all pending requests for |client|.
+  // Update the queue position for |request|, possibly causing it to start
+  // loading.
+  void ReprioritizeRequest(ScheduledResourceRequest* request);

[willchan no longer on Chromium, 2013/03/18 07:30:33]

There's some undocumented behavior here, namely the position of in the priority
queue. Whenever it moves, it is appended to the priority-specific queue. I'm
trying to figure out if that always makes sense. If an image moves out of the
viewport, should it be demoted and be at the end of the FIFO queue?

In any case, if nothing else, we should document that reprioritizations always
move the request to the end of the relevant queue.

Also note that it might not be in a queue, in which case it just reprioritizes
at the URLRequest level (when that's supported).

[James Simonsen, 2013/03/18 23:50:13]

Done.

I also thought about the always-at-end thing. It does make it harder for web
developers to reason about. However, from our perspective, if one request is
more important than the others, it should be a higher priority. IMO, we
shouldn't concern ourselves too much with strict FIFO.

+
+  // Attempts to load any pending requests in |client|, based on the
+  // ShouldStartRequest().
   void LoadPendingRequests(Client* client);

[willchan no longer on Chromium, 2013/03/18 07:30:33]

Nit: Can we get a better name? I leave it up to you, but when I read
LoadPendingRequests(), I think that it'll load all of the pending requests, not
"attempt" to load them.

[James Simonsen, 2013/03/18 23:50:13]

Done.

 
+  // Returns the number of requests with priority < LOW that are currently in
+  // flight.
+  int GetNumLowPriorityRequestsInFlight(Client* client);

[willchan no longer on Chromium, 2013/03/18 07:30:33]

Looks like it should be const

[James Simonsen, 2013/03/18 23:50:13]

Done.

+
+  // Returns true if the request should start. This is the core scheduling
+  // algorithm.
+  bool ShouldStartRequest(ScheduledResourceRequest* request, Client* client);

[willchan no longer on Chromium, 2013/03/18 07:30:33]

Looks like it should be const

[James Simonsen, 2013/03/18 23:50:13]

Done.

+
   // Returns the client ID for the given |child_id| and |route_id| combo.
   ClientId MakeClientId(int child_id, int route_id);