cc: Defer texture allocation (to allow async allocations).

cc: Defer texture allocation (to allow async allocations).

For textures, delay allocating until the first setPixels
or beginSetPixels. This allows us to do a combined async
allocation/upload in beginSetPixels.

BUG=161337
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=173875

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=174035

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=175884

[epenner, 2012-12-17 22:50:23]

Ptal. This passes existing tests, which cover basic use cases.

Is there any expectation that the texture be allocated for produce/consume? It
seems like transferring an empty/non-allocated texture is still 'valid', but
perhaps I should add a DCHECK in produce, since that is likely a bug?

[reveman, 2012-12-17 23:22:08]

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:940: } else {
how about always using asyncTexImage2DCHROMIUM here?

[piman, 2012-12-17 23:29:36]

test?

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:403: DCHECK(!resource->exported);
nit: Add a DCHECK(resource->allocated); here

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:664: resource.mailbox.setName(it->mailbox.name);
nit: set resource.allocated here

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:704: DCHECK(!source->external);
nit: Add a DCHECK(source->allocated); here

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:851: DCHECK(!resource->exported);
I think you need to lazy-allocate here.

[epennerAtGoogle, 2012-12-17 23:35:26]

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:940: } else {
On 2012/12/17 23:22:08, David Reveman wrote:
> how about always using asyncTexImage2DCHROMIUM here?

Hmm, we could maybe change the internals to make that efficient 'under the
hood', but it would involve using TexSubImage2D internally for good performance,
so I think it's more clear to just issue the real calls in the first place.

There is a semantic difference between the two in GL/EGL (TexImage2D will always
cause an allocation with no size change, and it will 'orphan' connected
EGLImages), so I like preserving those semantics.

[reveman, 2012-12-17 23:55:02]

On 2012/12/17 23:35:26, epennerAtGoogle wrote:
> https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc
> File cc/resource_provider.cc (right):
> 
>
https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
> cc/resource_provider.cc:940: } else {
> On 2012/12/17 23:22:08, David Reveman wrote:
> > how about always using asyncTexImage2DCHROMIUM here?
> 
> Hmm, we could maybe change the internals to make that efficient 'under the
> hood', but it would involve using TexSubImage2D internally for good
performance,
> so I think it's more clear to just issue the real calls in the first place.
> 
> There is a semantic difference between the two in GL/EGL (TexImage2D will
always
> cause an allocation with no size change, and it will 'orphan' connected
> EGLImages), so I like preserving those semantics.

ok, makes sense.

[epennerAtGoogle, 2012-12-18 00:12:34]

Test is on the way.

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:403: DCHECK(!resource->exported);
On 2012/12/17 23:29:36, piman wrote:
> nit: Add a DCHECK(resource->allocated); here

Done.

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:664: resource.mailbox.setName(it->mailbox.name);
On 2012/12/17 23:29:36, piman wrote:
> nit: set resource.allocated here
Done.

Is this to prevent an 'unauthorized' lazy allocation in the parent? This could
cause GL errors eventually when this texture is back in the child and it thinks
it is allocated. But assuming it's an error to send an empty texture in the
first place, that is fine?

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:704: DCHECK(!source->external);
On 2012/12/17 23:29:36, piman wrote:
> nit: Add a DCHECK(source->allocated); here

Done.

https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newco...
cc/resource_provider.cc:851: DCHECK(!resource->exported);
On 2012/12/17 23:29:36, piman wrote:
> I think you need to lazy-allocate here.
Thanks!! Done

[piman, 2012-12-18 00:30:15]

On Mon, Dec 17, 2012 at 4:12 PM, <epenner@google.com> wrote:

> Test is on the way.
>
>
>
> https://codereview.chromium.**org/11622008/diff/1/cc/**
>
resource_provider.cc<https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc>
> File cc/resource_provider.cc (right):
>
> https://codereview.chromium.**org/11622008/diff/1/cc/**
>
resource_provider.cc#**newcode403<https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newcode403>
> cc/resource_provider.cc:403: DCHECK(!resource->exported);
> On 2012/12/17 23:29:36, piman wrote:
>
>> nit: Add a DCHECK(resource->allocated); here
>>
>
> Done.
>
>
> https://codereview.chromium.**org/11622008/diff/1/cc/**
>
resource_provider.cc#**newcode664<https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newcode664>
> cc/resource_provider.cc:664:
resource.mailbox.setName(it->m**ailbox.name<http://mailbox.name>
> );
> On 2012/12/17 23:29:36, piman wrote:
>
>> nit: set resource.allocated here
>>
> Done.
>
> Is this to prevent an 'unauthorized' lazy allocation in the parent? This
> could cause GL errors eventually when this texture is back in the child
> and it thinks it is allocated. But assuming it's an error to send an
> empty texture in the first place, that is fine?


The idea is that it shouldn't be ok to send a resource that wasn't
allocated. Hence the DCHECK there. Now, when you receive it in the parent,
you should tag it as allocated (because it is), so that you don't trigger
the DCHECK in lockForRead.


>
>
> https://codereview.chromium.**org/11622008/diff/1/cc/**
>
resource_provider.cc#**newcode704<https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newcode704>
> cc/resource_provider.cc:704: DCHECK(!source->external);
> On 2012/12/17 23:29:36, piman wrote:
>
>> nit: Add a DCHECK(source->allocated); here
>>
>
> Done.
>
>
> https://codereview.chromium.**org/11622008/diff/1/cc/**
>
resource_provider.cc#**newcode851<https://codereview.chromium.org/11622008/diff/1/cc/resource_provider.cc#newcode851>
> cc/resource_provider.cc:851: DCHECK(!resource->exported);
> On 2012/12/17 23:29:36, piman wrote:
>
>> I think you need to lazy-allocate here.
>>
> Thanks!! Done
>
>
https://codereview.chromium.**org/11622008/<https://codereview.chromium.org/1...
>

[piman, 2012-12-18 00:30:47]

https://codereview.chromium.org/11622008/diff/7001/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/7001/cc/resource_provider.cc#ne...
cc/resource_provider.cc:872: }
I'd prefer if this code was shared with the version in setPixels. Maybe move to
a helper function?

[epenner, 2012-12-18 04:02:47]

Also added a test. Ptal.

https://codereview.chromium.org/11622008/diff/7001/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/7001/cc/resource_provider.cc#ne...
cc/resource_provider.cc:872: }
On 2012/12/18 00:30:47, piman wrote:
> I'd prefer if this code was shared with the version in setPixels. Maybe move
to
> a helper function?

Done.

[piman, 2012-12-18 04:12:34]

LGTM + nits

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider.cc#ne...
cc/resource_provider.cc:987: if (!resource->allocated) {
nit:
if (resource->allocated)
    return;

saves indentation below and clearly indicates the laziness aspect.

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
File cc/resource_provider_unittest.cc (right):

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:671: new
NiceMock<AllocationTrackingContext3D>))));
nit: mind breaking this into 2 statements for indenting sanity?
scoped_ptr<WebKit::WebGraphicsContext3D> context(new
NiceMock<AllocationTrackingContext3D>);
scoped_ptr<OutputSurface>
outputSurface(FakeOutputSurface::Create3d(context.Pass()));

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:677: uint8_t pixels[16];
nit: initialize! You can do = {0};

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:717: 
nit: 2 superfluous blank lines.

[epenner, 2012-12-18 04:23:51]

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider.cc#ne...
cc/resource_provider.cc:987: if (!resource->allocated) {
On 2012/12/18 04:12:34, piman wrote:
> nit:
> if (resource->allocated)
>     return;
> 
> saves indentation below and clearly indicates the laziness aspect.

Good point. Didn't double-check my cut/paste.

Done.

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
File cc/resource_provider_unittest.cc (right):

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:671: new
NiceMock<AllocationTrackingContext3D>))));
On 2012/12/18 04:12:34, piman wrote:
> nit: mind breaking this into 2 statements for indenting sanity?
> scoped_ptr<WebKit::WebGraphicsContext3D> context(new
> NiceMock<AllocationTrackingContext3D>);
> scoped_ptr<OutputSurface>
> outputSurface(FakeOutputSurface::Create3d(context.Pass()));

Done.

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:677: uint8_t pixels[16];
On 2012/12/18 04:12:34, piman wrote:
> nit: initialize! You can do = {0};

Wasn't used, but good point. Also, I didn't know about that way to init an
array. Cool!

Done.

[commit-bot: I haz the power, 2012-12-18 04:27:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/6003

[piman, 2012-12-18 04:36:01]

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
File cc/resource_provider_unittest.cc (right):

https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
cc/resource_provider_unittest.cc:677: uint8_t pixels[16];
On 2012/12/18 04:23:52, epenner wrote:
> On 2012/12/18 04:12:34, piman wrote:
> > nit: initialize! You can do = {0};
> 
> Wasn't used, but good point.

Just FYI, it's used below in resourceProvider->setPixels. While we don't
explicitly check the pixels, we don't want to copy around uninitialized data, it
makes the valgrind bots barf.

[epenner, 2012-12-18 04:52:24]

On 2012/12/18 04:36:01, piman wrote:
>
https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
> File cc/resource_provider_unittest.cc (right):
> 
>
https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unitt...
> cc/resource_provider_unittest.cc:677: uint8_t pixels[16];
> On 2012/12/18 04:23:52, epenner wrote:
> > On 2012/12/18 04:12:34, piman wrote:
> > > nit: initialize! You can do = {0};
> > 
> > Wasn't used, but good point.
> 
> Just FYI, it's used below in resourceProvider->setPixels. While we don't
> explicitly check the pixels, we don't want to copy around uninitialized data,
it
> makes the valgrind bots barf.

Gotcha I figured it was mocked and never accessed. But even still just good
practice you are right.

So some compositor tests are failing on the lockForRead DCHECK. I haven't
investigated too deeply yet. I'm testing without it, but if you think we need
it, I might need to take a deeper look at it.

[piman, 2012-12-18 06:29:01]

On Mon, Dec 17, 2012 at 8:52 PM, <epenner@chromium.org> wrote:

> On 2012/12/18 04:36:01, piman wrote:
>
> https://codereview.chromium.**org/11622008/diff/2002/cc/**
>
resource_provider_unittest.cc<https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unittest.cc>
>
>> File cc/resource_provider_unittest.**cc (right):
>>
>
>
> https://codereview.chromium.**org/11622008/diff/2002/cc/**
>
resource_provider_unittest.cc#**newcode677<https://codereview.chromium.org/11622008/diff/2002/cc/resource_provider_unittest.cc#newcode677>
>
>> cc/resource_provider_unittest.**cc:677: uint8_t pixels[16];
>> On 2012/12/18 04:23:52, epenner wrote:
>> > On 2012/12/18 04:12:34, piman wrote:
>> > > nit: initialize! You can do = {0};
>> >
>> > Wasn't used, but good point.
>>
>
>  Just FYI, it's used below in resourceProvider->setPixels. While we don't
>> explicitly check the pixels, we don't want to copy around uninitialized
>> data,
>>
> it
>
>> makes the valgrind bots barf.
>>
>
> Gotcha I figured it was mocked and never accessed. But even still just good
> practice you are right.
>
> So some compositor tests are failing on the lockForRead DCHECK. I haven't
> investigated too deeply yet. I'm testing without it, but if you think we
> need
> it, I might need to take a deeper look at it.
>

It means we are reading a texture that we haven't defined, and that sounds
like it's worth looking at: your patch would change the behavior from
reading black to generating GL errors. That said, it may be just tests
doing wonky things, but still..


>
>
https://codereview.chromium.**org/11622008/<https://codereview.chromium.org/1...
>

[epenner, 2012-12-18 22:28:24]

Okay, I kept the DCHECK which nicely lets us track reading from uninitialized
textures. However, I've used 'allocated' variants twice in production code to
fix current tests.

If the M25 cut hasn't happened, can we land this and I'll file a follow up bug?

[piman, 2012-12-18 22:41:38]

https://codereview.chromium.org/11622008/diff/16001/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/16001/cc/resource_provider.cc#n...
cc/resource_provider.cc:410: DCHECK(resource->allocated); // Texture
uninitialized! setPixels or lockForWrite first.
nit: 2 spaces before comments

https://codereview.chromium.org/11622008/diff/16001/cc/resource_provider.h
File cc/resource_provider.h (right):

https://codereview.chromium.org/11622008/diff/16001/cc/resource_provider.h#ne...
cc/resource_provider.h:80: ResourceId createAllocatedManagedResource(const
gfx::Size&, GLenum format, TextureUsageHint);
How about one explicit allocateResourceForTest(ResourceId) instead of 2 extra
entrypoints?

https://codereview.chromium.org/11622008/diff/16001/cc/scoped_resource.cc
File cc/scoped_resource.cc (right):

https://codereview.chromium.org/11622008/diff/16001/cc/scoped_resource.cc#new...
cc/scoped_resource.cc:24:
set_id(resource_provider_->createAllocatedResource(size, format, hint));
"for tests only" fails here. Why is this needed?

[epenner, 2012-12-19 00:37:05]

Okay, the last offender (doing an uninitialized read) was the HUD layer. Since
there might be untested code in Chrome, I still lazily allocate in lockForRead
for now.

Might be good to take another look.

[piman, 2012-12-19 00:45:49]

https://codereview.chromium.org/11622008/diff/20002/cc/heads_up_display_layer...
File cc/heads_up_display_layer_impl.cc (right):

https://codereview.chromium.org/11622008/diff/20002/cc/heads_up_display_layer...
cc/heads_up_display_layer_impl.cc:81: // TODO(epenner): This texture was being
used before setPixels was called,
nit: file a bug to clean up?

It sounds like the allocation should be done in updateHudTexture but I may be
missing something.

https://codereview.chromium.org/11622008/diff/20002/cc/resource_provider.cc
File cc/resource_provider.cc (right):

https://codereview.chromium.org/11622008/diff/20002/cc/resource_provider.cc#n...
cc/resource_provider.cc:398: lazyAllocate(resource);
I don't think that's useful -- we'll survive a GL error.

[epenner, 2012-12-19 01:18:03]

> It sounds like the allocation should be done in updateHudTexture but I may be
> missing something.

That's what I thought too, but I filed a bug against my self to do in another
CL. I'll add reviewer that made that file.

> I don't think that's useful -- we'll survive a GL error.

Done.

Removed it. Actually it might not even be an error, no? Aren't uninitialized
textures just black?

lgty?

[piman, 2012-12-19 01:22:39]

lgtm

[epenner, 2012-12-19 01:24:50]

I'm gonna land since looks like you are offline. But I'll make any follow up
changes if you have any.

[epenner, 2012-12-19 01:25:11]

On 2012/12/19 01:24:50, epenner wrote:
> I'm gonna land since looks like you are offline. But I'll make any follow up
> changes if you have any.

I spoke to soon ;) thanks!

[commit-bot: I haz the power, 2012-12-19 01:31:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/16002

[commit-bot: I haz the power, 2012-12-19 07:10:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/16002

[commit-bot: I haz the power, 2012-12-19 07:57:37]

Change committed as 173875

[epennerAtGoogle, 2012-12-19 21:15:27]

On 2012/12/19 07:57:37, I haz the power (commit-bot) wrote:
> Change committed as 173875

It was reverted due to a new test slipping in. Reproduced and fixed locally (one
line change in cc/test/render_pass_test_common.cc). Relanding.

[commit-bot: I haz the power, 2012-12-19 21:16:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/27008

[commit-bot: I haz the power, 2012-12-19 22:41:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/27008

[commit-bot: I haz the power, 2012-12-19 23:20:47]

Change committed as 174035

[epennerAtGoogle, 2012-12-21 03:34:02]

On 2012/12/19 23:20:47, I haz the power (commit-bot) wrote:
> Change committed as 174035

This was rolled out again and after finding two broken layout tests I'm a bit
less confident about this approach. The first was just a simple mistake from my
refactoring lazyAllocate (it needs a bindTexture in there now). 

But now, I've realized the allocation time has a subtle effect on the user of
the resource provider. See resource_update_controller.cc for a nasty example.

I'm not sure if I should keep this approach, or switch back to a more
conservative "CreateUnallocatedResource" (which doesn't effect old code).

[epenner, 2012-12-21 22:27:55]

Okay I've looked at every call-site for ScopedWriteLock and LockForWrite. There
isn't very many, and I don't see any other problems. It seems reasonable that
the caller should assume LockForWrite may need to interact with GL, so the lock
should indeed occur before the flush in resource_update_controller.

Third time lucky!

[commit-bot: I haz the power, 2012-12-21 22:28:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/21007

[commit-bot: I haz the power, 2012-12-22 02:15:49]

Retried try job too often on win_rel for step(s) browser_tests

[commit-bot: I haz the power, 2013-01-04 22:10:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/39001

[commit-bot: I haz the power, 2013-01-04 22:11:03]

Failed to apply patch for cc/layer_tree_host_impl_unittest.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file cc/layer_tree_host_impl_unittest.cc
  Hunk #1 succeeded at 1056 (offset -2 lines).
  Hunk #2 succeeded at 1682 (offset -2 lines).
  Hunk #3 FAILED at 2759.
  Hunk #4 FAILED at 2774.
  2 out of 4 hunks FAILED -- saving rejects to file
cc/layer_tree_host_impl_unittest.cc.rej

Patch:       cc/layer_tree_host_impl_unittest.cc
Index: cc/layer_tree_host_impl_unittest.cc
diff --git a/cc/layer_tree_host_impl_unittest.cc
b/cc/layer_tree_host_impl_unittest.cc
index
af6082d5d674291520c12615206b4276dd5107f5..d31f9f555303977727a878c410152cda6b1eb829
100644
--- a/cc/layer_tree_host_impl_unittest.cc
+++ b/cc/layer_tree_host_impl_unittest.cc
@@ -1058,6 +1058,7 @@ private:
         setSkipsDraw(skipsDraw);
         if (!tileMissing) {
             ResourceProvider::ResourceId resource =
resourceProvider->createResource(gfx::Size(), GL_RGBA,
ResourceProvider::TextureUsageAny);
+            resourceProvider->allocateForTesting(resource);
             pushTileProperties(0, 0, resource, gfx::Rect(), false);
         }
         if (animating)
@@ -1683,6 +1684,7 @@ private:
         , m_quadVisibleRect(5, 5, 5, 5)
         , m_resourceId(resourceProvider->createResource(gfx::Size(1, 1),
GL_RGBA, ResourceProvider::TextureUsageAny))
     {
+        resourceProvider->allocateForTesting(m_resourceId);
         setAnchorPoint(gfx::PointF(0, 0));
         setBounds(gfx::Size(10, 10));
         setContentBounds(gfx::Size(10, 10));
@@ -2757,9 +2759,15 @@ public:
         ResourceProvider::TextureUsageHint hint =
ResourceProvider::TextureUsageAny;
        
setScrollbarGeometry(ScrollbarGeometryFixedThumb::create(FakeWebScrollbarThemeGeometryNonEmpty::create()));
 
-        setBackTrackResourceId(provider->createResource(size, format, hint));
-        setForeTrackResourceId(provider->createResource(size, format, hint));
-        setThumbResourceId(provider->createResource(size, format, hint));
+        ResourceProvider::ResourceId backId  = provider->createResource(size,
format, hint);
+        ResourceProvider::ResourceId foreId  = provider->createResource(size,
format, hint);
+        ResourceProvider::ResourceId thumbId = provider->createResource(size,
format, hint);
+        provider->allocateForTesting(backId);
+        provider->allocateForTesting(foreId);
+        provider->allocateForTesting(thumbId);
+        setBackTrackResourceId(backId);
+        setForeTrackResourceId(foreId);
+        setThumbResourceId(thumbId);
     }
 
 protected:
@@ -2772,6 +2780,7 @@ protected:
 static inline scoped_ptr<RenderPass>
createRenderPassWithResource(ResourceProvider* provider)
 {
     ResourceProvider::ResourceId resourceId =
provider->createResource(gfx::Size(1, 1), GL_RGBA,
ResourceProvider::TextureUsageAny);
+    provider->allocateForTesting(resourceId);
 
     scoped_ptr<TestRenderPass> pass = TestRenderPass::Create();
     pass->SetNew(RenderPass::Id(1, 1), gfx::Rect(0, 0, 1, 1), gfx::Rect(0, 0,
1, 1), gfx::Transform());

[commit-bot: I haz the power, 2013-01-09 17:29:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/53001

[commit-bot: I haz the power, 2013-01-09 21:03:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/epenner@chromium.org/11622008/53001

[commit-bot: I haz the power, 2013-01-09 21:06:13]

Change committed as 175884