cc: Add image decode queue functionality to image manager.

cc/tiles/software_image_decode_cache.h

 // Copyright 2016 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.
 
 #ifndef CC_TILES_SOFTWARE_IMAGE_DECODE_CACHE_H_
 #define CC_TILES_SOFTWARE_IMAGE_DECODE_CACHE_H_
 
 #include <stdint.h>
 
 #include <memory>
@@ skipping 91 matching lines @@
 };
 
 class CC_EXPORT SoftwareImageDecodeCache
     : public ImageDecodeCache,
       public base::trace_event::MemoryDumpProvider,
       public base::MemoryCoordinatorClient {
  public:
   using ImageKey = ImageDecodeCacheKey;
   using ImageKeyHash = ImageDecodeCacheKeyHash;
 
+  enum class DecodeTaskType { USE_IN_RASTER_TASKS, USE_OUT_OF_RASTER_TASKS };
+
   SoftwareImageDecodeCache(ResourceFormat format,
                            size_t locked_memory_limit_bytes);
   ~SoftwareImageDecodeCache() override;
 
   // ImageDecodeCache overrides.
   bool GetTaskForImageAndRef(const DrawImage& image,
                              const TracingInfo& tracing_info,
                              scoped_refptr<TileTask>* task) override;
+  bool GetOutOfRasterDecodeTaskForImageAndRef(
+      const DrawImage& image,
+      scoped_refptr<TileTask>* task) override;
   void UnrefImage(const DrawImage& image) override;
   DecodedDrawImage GetDecodedImageForDraw(const DrawImage& image) override;
   void DrawWithImageFinished(const DrawImage& image,
                              const DecodedDrawImage& decoded_image) override;
   void ReduceCacheUsage() override;
   // Software doesn't keep outstanding images pinned, so this is a no-op.
   void SetShouldAggressivelyFreeResources(
       bool aggressively_free_resources) override {}
 
   // Decode the given image and store it in the cache. This is only called by an
   // image decode task from a worker thread.
-  void DecodeImage(const ImageKey& key, const DrawImage& image);
+  void DecodeImage(const ImageKey& key,
+                   const DrawImage& image,
+                   DecodeTaskType task_type);
 
-  void RemovePendingTask(const ImageKey& key);
+  void RemovePendingTask(const ImageKey& key, DecodeTaskType task_type);
 
   // MemoryDumpProvider overrides.
   bool OnMemoryDump(const base::trace_event::MemoryDumpArgs& args,
                     base::trace_event::ProcessMemoryDump* pmd) override;
 
  private:
   // DecodedImage is a convenience storage for discardable memory. It can also
   // construct an image out of SkImageInfo and stored discardable memory.
   class DecodedImage {
    public:
@@ skipping 116 matching lines @@
   void UnrefAtRasterImage(const ImageKey& key);
 
   // Helper function which dumps all images in a specific ImageMRUCache.
   void DumpImageMemoryForCache(const ImageMRUCache& cache,
                                const char* cache_name,
                                base::trace_event::ProcessMemoryDump* pmd) const;
 
   // Overriden from base::MemoryCoordinatorClient.
   void OnMemoryStateChange(base::MemoryState state) override;
 
+  // Helper method to get the different tasks. Note that this should be used as
+  // if it was public (ie, all of the locks need to be properly acquired).
+  bool GetTaskForImageAndRefInternal(const DrawImage& image,
+                                     const TracingInfo& tracing_info,
+                                     DecodeTaskType type,
+                                     scoped_refptr<TileTask>* task);
+
   std::unordered_map<ImageKey, scoped_refptr<TileTask>, ImageKeyHash>
-      pending_image_tasks_;
+      pending_in_raster_image_tasks_;

[enne (OOO), 2017/01/03 21:15:25]

Why do you need a second map for out of raster image tasks? How is the same
image appearing in both maps handled? Does it get decoded twice?

[vmpstr, 2017/01/03 21:40:34]

Yeah this is here as a safeguard against the task returned for the image queue
being used at the same time in raster/tile management. Because the image queue
calls "schedule/run/complete" sequences manually, it will crash/bad things will
happen if the raster system also uses the same task.

If the tile management requests the same image as the one queued in image queue,
then yes it will be decoded twice. However, the intent of the system is to not
give the images to the raster system unless the decode system says it's done, so
I think that's fine.

Note also that this is just for pending tasks, once the decode itself is done
and locked it goes into a common map.

[enne (OOO), 2017/01/03 21:49:42]

Ah, ok thanks.  That makes more sense why they need to be separate.

+  std::unordered_map<ImageKey, scoped_refptr<TileTask>, ImageKeyHash>
+      pending_out_of_raster_image_tasks_;
 
   // The members below this comment can only be accessed if the lock is held to
   // ensure that they are safe to access on multiple threads.
   base::Lock lock_;
 
   // Decoded images and ref counts (predecode path).
   ImageMRUCache decoded_images_;
   std::unordered_map<ImageKey, int, ImageKeyHash> decoded_images_ref_counts_;
 
   // Decoded image and ref counts (at-raster decode path).
   ImageMRUCache at_raster_decoded_images_;
   std::unordered_map<ImageKey, int, ImageKeyHash>
       at_raster_decoded_images_ref_counts_;
 
   MemoryBudget locked_images_budget_;
 
   ResourceFormat format_;
   size_t max_items_in_cache_;
 
   // Used to uniquely identify DecodedImages for memory traces.
   base::AtomicSequenceNumber next_tracing_id_;
 };
 
 }  // namespace cc
 
 #endif  // CC_TILES_SOFTWARE_IMAGE_DECODE_CACHE_H_