cc: Refactor additional code from BuildRasterQueue.

cc/resources/tile_manager.cc

 // Copyright 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/resources/tile_manager.h"
 
 #include <algorithm>
 #include <limits>
 #include <string>
 
@@ skipping 344 matching lines @@
       did_check_for_completed_tasks_since_last_schedule_tasks_ = true;
     }
 
     FreeResourcesForReleasedTiles();
     CleanUpReleasedTiles();
 
     TileVector tiles_that_need_to_be_rasterized;
     scoped_ptr<RasterTilePriorityQueue> raster_priority_queue(
         client_->BuildRasterQueue(global_state_.tree_priority,
                                   RasterTilePriorityQueue::Type::ALL));
+    // Inform the client that will likely require a draw if the top tile is
+    // required for draw.
+    client_->SetIsLikelyToRequireADraw(

[vmpstr, 2015/01/26 22:08:35]

I think this is the only spot that makes sense we add this call. Alternatively,
we can add it to every spot that rebuilds the raster queue. That, however, is
iffy since some of the calls are almost certainly will set this to false
(scheduling more work after the initial batch is done) and some don't really
make sense to me (building it with intent of marking tiles rasterize on demand).

[danakj, 2015/01/29 22:33:20]

Once the initial batch of work is done, if the top of the queue is not required,
we should tell the LTHI so and stop queuing frames tho?

[vmpstr, 2015/01/29 22:48:09]

Well.. I don't think so... I mean when we draw, we will reset the flag until its
set again. So suppose the situation is that we queue 1 tiles that is required to
draw, so we SetIsLikelyToRequireDraw but then it finishes really quickly and we
get to the reschedule and find that the top tile is not required. I think in
that case, we should leave the flag whatever it was, no? If we had it at
is_likely_to_draw_ = true, then that's still the case since we finished a now
tile and didn't have a draw yet, and if it's false then leave it at false.

[danakj, 2015/01/29 23:05:34]

well, i'm not sure it matters but take a look at LTHI::NotifyReadyToDraw(). When
a tile becomes ready, we SetNeedsRedraw then and stop doing it in
WillBeginFrame. If there was only one tile then we'd have already set it to
false. So I guess this is good. Less codepaths to follow with same result.

+        !raster_priority_queue->IsEmpty() &&
+        raster_priority_queue->Top()->required_for_draw());
     AssignGpuMemoryToTiles(raster_priority_queue.get(),
                            scheduled_raster_task_limit_,
                            &tiles_that_need_to_be_rasterized);
 
     // Schedule tile tasks.
     ScheduleTasks(tiles_that_need_to_be_rasterized);
 
     did_notify_ready_to_activate_ = false;
     did_notify_ready_to_draw_ = false;
   } else {
@@ skipping 665 matching lines @@
   result -= other;
   return result;
 }
 
 bool TileManager::MemoryUsage::Exceeds(const MemoryUsage& limit) const {
   return memory_bytes_ > limit.memory_bytes_ ||
          resource_count_ > limit.resource_count_;
 }
 
 }  // namespace cc