Enable removing uploads to evicted textures from texture upload queues.

cc/CCPrioritizedTexture.cpp

 // 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 "config.h"
 
 #include "CCPrioritizedTexture.h"
 
 #include "CCPrioritizedTextureManager.h"
 #include "CCPriorityCalculator.h"
@@ skipping 108 matching lines @@
     setIsSelfManaged(true);
     m_bytes = bytes;
 }
 
 CCPrioritizedTexture::Backing::Backing(unsigned id, IntSize size, GC3Denum format)
     : CCTexture(id, size, format)
     , m_owner(0)
     , m_priorityAtLastPriorityUpdate(CCPriorityCalculator::lowestPriority())
     , m_ownerExistedAtLastPriorityUpdate(false)
     , m_wasAbovePriorityCutoffAtLastPriorityUpdate(false)
+    , m_resourceHasBeenDeleted(false)
 {
 }
 
 CCPrioritizedTexture::Backing::~Backing()
 {
     ASSERT(!m_owner);
+    ASSERT(m_resourceHasBeenDeleted);
+}
+
+void CCPrioritizedTexture::Backing::deleteResource(CCResourceProvider* resourceProvider)

[jamesr, 2012/09/19 18:56:37]

could we at least in debug verify that the provider used to delete the resource
is the same that was used to create it? perhaps keep a pointer around in #ifndef
NDEBUG?

why the asymmetry between creating the resource and deleting it? the manager
always creates and most of the time deletes the resource, but in this path
deletion is through the backing. would it be cleaner to leave all
CCResourceProvider interactions in the manager and have the backing be more of a
container of ids/properties?

[ccameron, 2012/09/19 20:52:02]

Added.
It's asymmetric because we always create a backing structure and its resource at
the same time, while we will delete the backing structure and its resource at
different times (this, in turn, is because we can delete the resource while the
main thread is running, but we cannot unlink backings while the main thread is
running).  All deletion paths go through the sequence
"evictBackingsToReduceMemory calls evictBackingResource calls deleteResource" at
the end.

I played around with separating the creation into two steps to be symmetric, but
the result was more confusing to read (it then appeared to support or use
behavior that we didn't).

+{
+    ASSERT(CCProxy::isImplThread());
+    ASSERT(!m_resourceHasBeenDeleted);
+
+    resourceProvider->deleteResource(id());
+    setId(0);
+    m_resourceHasBeenDeleted = true;
+}
+
+bool CCPrioritizedTexture::Backing::resourceHasBeenDeleted() const
+{
+    ASSERT(CCProxy::isImplThread());
+    return m_resourceHasBeenDeleted;
 }
 
 void CCPrioritizedTexture::Backing::updatePriority()
 {
     ASSERT(CCProxy::isImplThread() && CCProxy::isMainThreadBlocked());
     if (m_owner) {
         m_ownerExistedAtLastPriorityUpdate = true;
         m_priorityAtLastPriorityUpdate = m_owner->requestPriority();
         m_wasAbovePriorityCutoffAtLastPriorityUpdate = m_owner->isAbovePriorityCutoff();
     } else {
         m_ownerExistedAtLastPriorityUpdate = false;
         m_priorityAtLastPriorityUpdate = CCPriorityCalculator::lowestPriority();
         m_wasAbovePriorityCutoffAtLastPriorityUpdate = false;
     }
 }
 
 } // namespace cc