Aura: Have ui::Layer implement WebKit::WebExternalTextureLayerClient

Aura: Have ui::Layer implement WebKit::WebExternalTextureLayerClient

With --ui-enable-threaded-compositing, every Layer::SetExternalTexture() was causing a heavy CCThreadProxy::acquireLayerTextures(). This synchronization is unnecessary on the common case of buffer flips, because RWHVA handles the necessary synchronization via OnCompositingWillStart callbacks.

To reduce the synchronization burden, we handle
- wait for a commit on resize fast ACKS
- handle the common case of buffer flips via WebExternalTextureLayerClient::prepareTexture()
- and explicitly call WebExternalTextureLayer::willModifyTexture() when we need the extra synchronization on tear down.

BUG=136012
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=146621

[jonathan.backer, 2012-07-09 14:43:38]

I think I've got all the synchronization issues covered (other than the resize
lock -- separate CL).

I opted for the DidCommit callback API so that I could easily handle the
threaded and non-threaded case. Also, I didn't want to add yet another method to
CompositorObserver.

[piman, 2012-07-09 22:40:00]

https://chromiumcodereview.appspot.com/10689108/diff/4001/content/browser/ren...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/content/browser/ren...
content/browser/renderer_host/render_widget_host_view_aura.cc:555:
InsertSyncPointAndACK(params_in_pixel.route_id, gpu_host_id, compositor);
compositor is NULL here. I don't think this works (it was broken before, but
this makes it more evident...)

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
File ui/compositor/compositor.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
ui/compositor/compositor.cc:348: void Compositor::didCommit() {
Can you add a comment that this is only called in the compositor thread case?

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
File ui/compositor/compositor.h (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
ui/compositor/compositor.h:224: void AddDidCommitCallback(
It would be good to have the name and/or comments indicate that in the
single-threaded case, this would run the callback immediately (in a re-entrant
way). It can be unexpected to the user

[jonathan.backer, 2012-07-11 21:02:02]

I ripped out ImageTransportClient because it was effectively dead (perhaps used
in tests --- but I doubt it). The trybots don't seem to choking on it. I hope
this is alright. I don't think it was a useful abstraction anymore.

I feel like this is moving in the right direction. I'm worried about a stale
Texture::hostContext3D(). But I think I'm covered by host_.reset() added to
~Compositor and RWHVA::OnLostResources.

https://chromiumcodereview.appspot.com/10689108/diff/4001/content/browser/ren...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/content/browser/ren...
content/browser/renderer_host/render_widget_host_view_aura.cc:555:
InsertSyncPointAndACK(params_in_pixel.route_id, gpu_host_id, compositor);
On 2012/07/09 22:40:01, piman wrote:
> compositor is NULL here. I don't think this works (it was broken before, but
> this makes it more evident...)

Good catch. The right thing to do here is to return a 0 sync point. Then
TextureImageTransportSurface won't wait for it on the service side.

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
File ui/compositor/compositor.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
ui/compositor/compositor.cc:348: void Compositor::didCommit() {
On 2012/07/09 22:40:01, piman wrote:
> Can you add a comment that this is only called in the compositor thread case?

I was wrong. It's not. But it's only called during a draw in the single-threaded
case, whereas it can be called many times per draw in the threaded case.

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
File ui/compositor/compositor.h (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
ui/compositor/compositor.h:224: void AddDidCommitCallback(
On 2012/07/09 22:40:01, piman wrote:
> It would be good to have the name and/or comments indicate that in the
> single-threaded case, this would run the callback immediately (in a re-entrant
> way). It can be unexpected to the user

You're right: it's confusing. I changed it to fire on all didCommit() signals.
If you'd like, I can add this to CompositorObserver instead (although that's
getting pretty full).

Based on our conversation, I dug deeper. In the single-threaded case,
didCommit() is signaled halfway through a draw cycle. Whereas in the threaded
case, didCommit() happens quickly after a setNeedsCommit() and can occur many
times before a draw cycle.

[piman, 2012-07-12 00:18:09]

At a high level, logic looks fine.
Thanks for removing ImageTransportClient, I think that's good.

There's a couple of small things, mostly nits, but also if it makes sense, I'd
rather make the didCommit forwarding through the CompositorObserver for
consistency.

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
File ui/compositor/compositor.h (right):

https://chromiumcodereview.appspot.com/10689108/diff/4001/ui/compositor/compo...
ui/compositor/compositor.h:224: void AddDidCommitCallback(
On 2012/07/11 21:02:03, jonathan.backer wrote:
> On 2012/07/09 22:40:01, piman wrote:
> > It would be good to have the name and/or comments indicate that in the
> > single-threaded case, this would run the callback immediately (in a
re-entrant
> > way). It can be unexpected to the user
> 
> You're right: it's confusing. I changed it to fire on all didCommit() signals.
> If you'd like, I can add this to CompositorObserver instead (although that's
> getting pretty full).

I'd rather be consistent.

> Based on our conversation, I dug deeper. In the single-threaded case,
> didCommit() is signaled halfway through a draw cycle. Whereas in the threaded
> case, didCommit() happens quickly after a setNeedsCommit() and can occur many
> times before a draw cycle.

Ok, thanks.

https://chromiumcodereview.appspot.com/10689108/diff/15021/content/browser/re...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/content/browser/re...
content/browser/renderer_host/render_widget_host_view_aura.cc:574:
switches::kUIEnableThreadedCompositing)) {
Rather than testing the command line (and parsing strings etc.) every frame, we
should probably make this a function on ui::Compositor.

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
File ui/compositor/compositor.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
ui/compositor/compositor.cc:359: it->Run(this);
btw, you run the risk of the closure modifying did_commit_callbacks_.
FWIW FOR_EACH_OBSERVER deals with this correctly.

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
File ui/compositor/compositor.h (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
ui/compositor/compositor.h:108: virtual WebKit::WebGraphicsContext3D*
hostContext3D() = 0;
nit: chrome style.

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/laye...
File ui/compositor/layer.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/laye...
ui/compositor/layer.cc:318: if (!web_layer_.isNull()) {
I don't think web_layer_.isNull() is ever true (we create one in the
constructor, and we always replace it with another valid one). So I think we
should remove the test.

[jonathan.backer, 2012-07-12 13:53:22]

Addressed comments, including add DidCommit to CompositorObservers.

The only substantial change in this revision was using TestWebGraphicsContext3D
in TestImageTransportFactory and adding a TRACE_EVENT to
TestWebGraphicsContext3D::SwapBuffers   to make some GpuBrowserTests pass
(AllowWebGL, AllowCanvas2D, etc).

https://chromiumcodereview.appspot.com/10689108/diff/15021/content/browser/re...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/content/browser/re...
content/browser/renderer_host/render_widget_host_view_aura.cc:574:
switches::kUIEnableThreadedCompositing)) {
On 2012/07/12 00:18:09, piman wrote:
> Rather than testing the command line (and parsing strings etc.) every frame,
we
> should probably make this a function on ui::Compositor.

Done.

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
File ui/compositor/compositor.h (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/comp...
ui/compositor/compositor.h:108: virtual WebKit::WebGraphicsContext3D*
hostContext3D() = 0;
On 2012/07/12 00:18:09, piman wrote:
> nit: chrome style.

Done.

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/laye...
File ui/compositor/layer.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/15021/ui/compositor/laye...
ui/compositor/layer.cc:318: if (!web_layer_.isNull()) {
On 2012/07/12 00:18:09, piman wrote:
> I don't think web_layer_.isNull() is ever true (we create one in the
> constructor, and we always replace it with another valid one). So I think we
> should remove the test.

Thanks. Done.

[piman, 2012-07-12 17:42:27]

LGTM. A couple of nits.

https://chromiumcodereview.appspot.com/10689108/diff/5027/content/browser/ren...
File content/browser/renderer_host/image_transport_factory.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/5027/content/browser/ren...
content/browser/renderer_host/image_transport_factory.cc:152: // A weak pointer.
This |ImageTransportClientTexture| will be destroyed
Nit: s/weak/raw/ to avoid confusion with WeakPtr

https://chromiumcodereview.appspot.com/10689108/diff/5027/ui/compositor/compo...
File ui/compositor/compositor.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/5027/ui/compositor/compo...
ui/compositor/compositor.cc:166: didCommit();
Is this still needed? I figure by the time we get here, the RWHVA will have been
removed from the tree and so they will do whatever is necessary to execute their
callbacks before then.
I guess my main question is what makes didCommit special as opposed to all the
other ones in CompositorObserver.

[jonathan.backer, 2012-07-13 13:26:24]

Runs fine locally. Waiting for try jobs.

https://chromiumcodereview.appspot.com/10689108/diff/5027/content/browser/ren...
File content/browser/renderer_host/image_transport_factory.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/5027/content/browser/ren...
content/browser/renderer_host/image_transport_factory.cc:152: // A weak pointer.
This |ImageTransportClientTexture| will be destroyed
On 2012/07/12 17:42:27, piman wrote:
> Nit: s/weak/raw/ to avoid confusion with WeakPtr

Done.

https://chromiumcodereview.appspot.com/10689108/diff/5027/ui/compositor/compo...
File ui/compositor/compositor.cc (right):

https://chromiumcodereview.appspot.com/10689108/diff/5027/ui/compositor/compo...
ui/compositor/compositor.cc:166: didCommit();
On 2012/07/12 17:42:27, piman wrote:
> Is this still needed? I figure by the time we get here, the RWHVA will have
been
> removed from the tree and so they will do whatever is necessary to execute
their
> callbacks before then.
> I guess my main question is what makes didCommit special as opposed to all the
> other ones in CompositorObserver.

You're right. There's nothing special. We'll leave it up to the
CompositorObserver. I checked with breakpoints and we're covered.

Done.

[jonathan.backer, 2012-07-13 15:22:09]

piman: Can you check the content/common/gpu changes? 

+zmo for chrome/test/gpu OWNERS: using a real compositor for the
GpuFeatureBrowserTests --- similar to GpuPixelBrowserTests

+ben for content/browser OWNERS: it's been reviewed by piman@ --- mostly nixing
dead code.

[Ben Goodger (Google), 2012-07-13 16:33:32]

lgtm

[piman, 2012-07-13 16:44:33]

lgtm

[Ken Russell (switch to Gerrit), 2012-07-13 17:44:38]

chrome/test/gpu/ LGTM

[commit-bot: I haz the power, 2012-07-13 17:45:48]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/backer@chromium.org/10689108/6008

[commit-bot: I haz the power, 2012-07-13 17:46:03]

Presubmit check for 10689108-6008 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    content

Presubmit checks took 1.9s to calculate.

[jam, 2012-07-13 17:54:24]

lgtm for the gypi (the rest has owners)

[commit-bot: I haz the power, 2012-07-13 18:00:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/backer@chromium.org/10689108/6008

[commit-bot: I haz the power, 2012-07-13 19:35:42]

Change committed as 146621

[jbates, 2012-07-18 22:50:28]

https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (left):

https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
gpu/command_buffer/service/gles2_cmd_decoder.cc:8237:
TRACE_EVENT_INSTANT2("test_gpu", "SwapBuffers",
why did this move? it changed the windows WebGL latency results so I don't think
this was correct.

[jonathan.backer, 2012-07-19 13:04:31]

https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
File gpu/command_buffer/service/gles2_cmd_decoder.cc (left):

https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
gpu/command_buffer/service/gles2_cmd_decoder.cc:8237:
TRACE_EVENT_INSTANT2("test_gpu", "SwapBuffers",
On 2012/07/18 22:50:28, jbates wrote:
> why did this move? it changed the windows WebGL latency results so I don't
think
> this was correct.

This moved because I had CrOS use a real display for GpuFeatureTests in order to
remove some dead code (http://codereview.chromium.org/10696221/) that was only
being used in test (it used to be used in production, but had been deprecated a
month or two ago).

More specifically, CrOS uses the GPU process to display it's UI. So any time a
window move, a menu opened, or new tab contents need display, we'd trigger a
SwapBuffers in the decoder process. It was clear that GpuFeatureTests only meant
to grab renderer SwapBuffers. Moving this to ImageTransportSurface achieves this
goal.

As for why this affects latency, we're now signalling a SwapBuffers after it has
been acted on, rather than before. Specifically,
PbufferImageTransportSurface::SwapBuffers() defers to a fence before telling the
browser that there is a new frame to display. I'm not sure what you're trying to
measure, but my gut tells me that this is probably what you want --- this fence
introduces latency that is user visible (and a quick search in content/browser/
for "test_gpu" comes up empty for windows, suggesting that it's not accounted
for in some other way).

If this is definitely not what you want, let me know and I can work around it.

[jbates, 2012-07-19 15:14:37]

On 2012/07/19 13:04:31, jonathan.backer wrote:
>
https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
> File gpu/command_buffer/service/gles2_cmd_decoder.cc (left):
> 
>
https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/...
> gpu/command_buffer/service/gles2_cmd_decoder.cc:8237:
> TRACE_EVENT_INSTANT2("test_gpu", "SwapBuffers",
> On 2012/07/18 22:50:28, jbates wrote:
> > why did this move? it changed the windows WebGL latency results so I don't
> think
> > this was correct.
> 
> This moved because I had CrOS use a real display for GpuFeatureTests in order
to
> remove some dead code (http://codereview.chromium.org/10696221/) that was only
> being used in test (it used to be used in production, but had been deprecated
a
> month or two ago).
> 
> More specifically, CrOS uses the GPU process to display it's UI. So any time a
> window move, a menu opened, or new tab contents need display, we'd trigger a
> SwapBuffers in the decoder process. It was clear that GpuFeatureTests only
meant
> to grab renderer SwapBuffers. Moving this to ImageTransportSurface achieves
this
> goal.

I guess the problem is this event is also used by performance_browser_tests
(latency_test.cc) with specific timing requirements. It must be where it was for
latency tests. However, it sounds like there will need to be some more tweaks to
get the latency_test to run on CrOS, but as of yet performance_browser_tests
does not run on CrOS.

One solution for now is to copy the SwapBuffers event back to where it was and
rename it to something like SwapBuffersLatency. Then update latency_test.cc to
use SwapBuffersLatency instead of SwapBuffers..

> 
> As for why this affects latency, we're now signalling a SwapBuffers after it
has
> been acted on, rather than before. Specifically,
> PbufferImageTransportSurface::SwapBuffers() defers to a fence before telling
the
> browser that there is a new frame to display. I'm not sure what you're trying
to
> measure, but my gut tells me that this is probably what you want --- this
fence
> introduces latency that is user visible (and a quick search in
content/browser/
> for "test_gpu" comes up empty for windows, suggesting that it's not accounted
> for in some other way).
> 
> If this is definitely not what you want, let me know and I can work around it.

[piman, 2012-07-19 16:56:48]

On Thu, Jul 19, 2012 at 8:14 AM, <jbates@chromium.org> wrote:

> On 2012/07/19 13:04:31, jonathan.backer wrote:
>
> https://chromiumcodereview.**appspot.com/10689108/diff/**
>
6008/gpu/command_buffer/**service/gles2_cmd_decoder.cc<https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/service/gles2_cmd_decoder.cc>
>
>> File gpu/command_buffer/service/**gles2_cmd_decoder.cc (left):
>>
>
>
> https://chromiumcodereview.**appspot.com/10689108/diff/**
>
6008/gpu/command_buffer/**service/gles2_cmd_decoder.cc#**oldcode8237<https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/service/gles2_cmd_decoder.cc#oldcode8237>
>
>> gpu/command_buffer/service/**gles2_cmd_decoder.cc:8237:
>> TRACE_EVENT_INSTANT2("test_**gpu", "SwapBuffers",
>> On 2012/07/18 22:50:28, jbates wrote:
>> > why did this move? it changed the windows WebGL latency results so I
>> don't
>> think
>> > this was correct.
>>
>
>  This moved because I had CrOS use a real display for GpuFeatureTests in
>> order
>>
> to
>
>> remove some dead code
(http://codereview.chromium.**org/10696221/<http://codereview.chromium.org/106...)
>> that was only
>> being used in test (it used to be used in production, but had been
>> deprecated
>>
> a
>
>> month or two ago).
>>
>
>  More specifically, CrOS uses the GPU process to display it's UI. So any
>> time a
>> window move, a menu opened, or new tab contents need display, we'd
>> trigger a
>> SwapBuffers in the decoder process. It was clear that GpuFeatureTests only
>>
> meant
>
>> to grab renderer SwapBuffers. Moving this to ImageTransportSurface
>> achieves
>>
> this
>
>> goal.
>>
>
> I guess the problem is this event is also used by performance_browser_tests
> (latency_test.cc) with specific timing requirements. It must be where it
> was for
> latency tests. However, it sounds like there will need to be some more
> tweaks to
> get the latency_test to run on CrOS, but as of yet
> performance_browser_tests
> does not run on CrOS.
>

Shouldn't we just update test expectations?

Antoine


>
> One solution for now is to copy the SwapBuffers event back to where it was
> and
> rename it to something like SwapBuffersLatency. Then update
> latency_test.cc to
> use SwapBuffersLatency instead of SwapBuffers..
>
>
>
>  As for why this affects latency, we're now signalling a SwapBuffers after
>> it
>>
> has
>
>> been acted on, rather than before. Specifically,
>> PbufferImageTransportSurface::**SwapBuffers() defers to a fence before
>> telling
>>
> the
>
>> browser that there is a new frame to display. I'm not sure what you're
>> trying
>>
> to
>
>> measure, but my gut tells me that this is probably what you want --- this
>>
> fence
>
>> introduces latency that is user visible (and a quick search in
>>
> content/browser/
>
>> for "test_gpu" comes up empty for windows, suggesting that it's not
>> accounted
>> for in some other way).
>>
>
>  If this is definitely not what you want, let me know and I can work
>> around it.
>>
>
>
>
>
https://chromiumcodereview.**appspot.com/10689108/<https://chromiumcodereview...
>

[jbates, 2012-07-21 05:27:26]

On 2012/07/19 16:56:48, piman wrote:
> On Thu, Jul 19, 2012 at 8:14 AM, <mailto:jbates@chromium.org> wrote:
> 
> > On 2012/07/19 13:04:31, jonathan.backer wrote:
> >
> > https://chromiumcodereview.**appspot.com/10689108/diff/**
> >
>
6008/gpu/command_buffer/**service/gles2_cmd_decoder.cc<https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/service/gles2_cmd_decoder.cc>
> >
> >> File gpu/command_buffer/service/**gles2_cmd_decoder.cc (left):
> >>
> >
> >
> > https://chromiumcodereview.**appspot.com/10689108/diff/**
> >
>
6008/gpu/command_buffer/**service/gles2_cmd_decoder.cc#**oldcode8237<https://chromiumcodereview.appspot.com/10689108/diff/6008/gpu/command_buffer/service/gles2_cmd_decoder.cc#oldcode8237>
> >
> >> gpu/command_buffer/service/**gles2_cmd_decoder.cc:8237:
> >> TRACE_EVENT_INSTANT2("test_**gpu", "SwapBuffers",
> >> On 2012/07/18 22:50:28, jbates wrote:
> >> > why did this move? it changed the windows WebGL latency results so I
> >> don't
> >> think
> >> > this was correct.
> >>
> >
> >  This moved because I had CrOS use a real display for GpuFeatureTests in
> >> order
> >>
> > to
> >
> >> remove some dead code
>
(http://codereview.chromium.**org/10696221/%3Chttp://codereview.chromium.org/1...>)
> >> that was only
> >> being used in test (it used to be used in production, but had been
> >> deprecated
> >>
> > a
> >
> >> month or two ago).
> >>
> >
> >  More specifically, CrOS uses the GPU process to display it's UI. So any
> >> time a
> >> window move, a menu opened, or new tab contents need display, we'd
> >> trigger a
> >> SwapBuffers in the decoder process. It was clear that GpuFeatureTests only
> >>
> > meant
> >
> >> to grab renderer SwapBuffers. Moving this to ImageTransportSurface
> >> achieves
> >>
> > this
> >
> >> goal.
> >>
> >
> > I guess the problem is this event is also used by performance_browser_tests
> > (latency_test.cc) with specific timing requirements. It must be where it
> > was for
> > latency tests. However, it sounds like there will need to be some more
> > tweaks to
> > get the latency_test to run on CrOS, but as of yet
> > performance_browser_tests
> > does not run on CrOS.
> >
> 
> Shouldn't we just update test expectations?

The new latency is invalid rather than different. I don't even really know
exactly what it's measuring because it was designed to expect the swap to be
synchronous with the webgl context blit.

> 
> Antoine
> 
> 
> >
> > One solution for now is to copy the SwapBuffers event back to where it was
> > and
> > rename it to something like SwapBuffersLatency. Then update
> > latency_test.cc to
> > use SwapBuffersLatency instead of SwapBuffers..
> >
> >
> >
> >  As for why this affects latency, we're now signalling a SwapBuffers after
> >> it
> >>
> > has
> >
> >> been acted on, rather than before. Specifically,
> >> PbufferImageTransportSurface::**SwapBuffers() defers to a fence before
> >> telling
> >>
> > the
> >
> >> browser that there is a new frame to display. I'm not sure what you're
> >> trying
> >>
> > to
> >
> >> measure, but my gut tells me that this is probably what you want --- this
> >>
> > fence
> >
> >> introduces latency that is user visible (and a quick search in
> >>
> > content/browser/
> >
> >> for "test_gpu" comes up empty for windows, suggesting that it's not
> >> accounted
> >> for in some other way).
> >>
> >
> >  If this is definitely not what you want, let me know and I can work
> >> around it.
> >>
> >
> >
> >
> >
>
https://chromiumcodereview.**appspot.com/10689108/%3Chttps://chromiumcoderevi...>
> >