Use WebKit compositor in ui::Layer

Use WebKit compositor in ui::Layer

BUG=99524
TEST=compositor_unittests


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

[piman, 2011-10-15 02:16:16]

This is still behind a compile-time flag (use_webkit_compositor=1). Also
accelerated compositing of web pages is currently disabled (follow-up patch,
that depends on more webkit stuff).

I tried to mostly keep #ifdefs away from layer.cc. ui::Layer is difficult to
abstract though, without duplicating a lot of code. Mostly the code deals with
it by creating the webkit layer based on the #ifdef, but only setting values on
it if it's present (as a run-time branch).
Hopefully a lot of this can be cleaned up once all the clients can use the
webkit compositor.

[Ben Goodger (Google), 2011-10-16 22:39:51]

http://codereview.chromium.org/8222028/diff/5001/ui/aura_shell/DEPS
File ui/aura_shell/DEPS (right):

http://codereview.chromium.org/8222028/diff/5001/ui/aura_shell/DEPS#newcode10
ui/aura_shell/DEPS:10: "+webkit/glue",
add a comment here to note that this isn't an invitation to include webkit stuff
here left and right... it's just until CC is a separate module

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor.cc
File ui/gfx/compositor/compositor.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.cc:28: void Compositor::OnRootLayerChanged() {
please keep the order of functions in the .cc in sync with the .h

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor.h
File ui/gfx/compositor/compositor.h (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.h:110: virtual void ScheduleDraw() {
this probably shouldn't be inlined anymore

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:115: void CompositorCC::ScheduleDraw() {
order of functions in the .cc file should match .h

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.h (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:53: virtual void OnWidgetSizeChanged()
OVERRIDE;
// Compositor

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc
File ui/gfx/compositor/layer.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:66: if (!web_layer_.isNull())
I'd actually rather see #ifdefs in this file... given that when we flip the
switch we probably won't want all these null checks.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:327: void Layer::RecomputeDrawsContent() {
order in .cc should match .h

[jonathan.backer, 2011-10-18 15:28:25]

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor.gyp (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.gyp:92: 'sources!': [
Maybe I'm not reading this correctly, but it looks like you're excluding sources
that you want to include.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:7: #include "base/bind.h"
necessary?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:9: #include "base/message_loop_proxy.h"
necessary?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:13: #include "ui/gfx/compositor/layer.h"
necessary?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.h (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:10: #include "base/memory/scoped_ptr.h"
necessary?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:11: #include "base/memory/ref_counted.h"
necessary?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:17: #include
"third_party/WebKit/Source/WebKit/chromium/public/WebLayerTreeViewClient.h"
nit: 80 column limit?

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:50: static void TerminateThread();
I don't see where these are called.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc
File ui/gfx/compositor/layer.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:1: // Copyright (c) 2011 The Chromium Authors. All
rights reserved.
Just a high level comment (feel free to ignore). This code is going to get hard
to read. Seems to me that with compositor CC, most of the code here is ignored.
Maybe hide the two implementations behind a factory? Then it's obvious what code
is active where rather than having a trail of #ifdefs to decipher.

[Ben Goodger (Google), 2011-10-18 15:40:40]

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc
File ui/gfx/compositor/layer.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:1: // Copyright (c) 2011 The Chromium Authors. All
rights reserved.
Seems like we'd need to extract some of this code as a base then, since we have
lots of conversion/utility functions here too.

[piman, 2011-10-19 17:53:23]

http://codereview.chromium.org/8222028/diff/5001/ui/aura_shell/DEPS
File ui/aura_shell/DEPS (right):

http://codereview.chromium.org/8222028/diff/5001/ui/aura_shell/DEPS#newcode10
ui/aura_shell/DEPS:10: "+webkit/glue",
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> add a comment here to note that this isn't an invitation to include webkit
stuff
> here left and right... it's just until CC is a separate module

In this patch I actually separated the compositor test support into its own
module (in ui/gfx/compositor), so that we don't need to explicitly initialize
webkit, and so I could remove this rule.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor.cc
File ui/gfx/compositor/compositor.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.cc:28: void Compositor::OnRootLayerChanged() {
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> please keep the order of functions in the .cc in sync with the .h

Done.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor.gyp (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.gyp:92: 'sources!': [
On 2011/10/18 15:28:26, jonathan.backer wrote:
> Maybe I'm not reading this correctly, but it looks like you're excluding
sources
> that you want to include.

This is the "else" clause (i.e. use_webkit_compositor != 1), so I'm removing the
_cc files ('sources!')

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor.h
File ui/gfx/compositor/compositor.h (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.h:110: virtual void ScheduleDraw() {
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> this probably shouldn't be inlined anymore

Done.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:7: #include "base/bind.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> necessary?

Gone

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:9: #include "base/message_loop_proxy.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> necessary?

Gone.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:13: #include "ui/gfx/compositor/layer.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> necessary?

Just necessary for root_layer()->web_layer().

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.cc:115: void CompositorCC::ScheduleDraw() {
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> order of functions in the .cc file should match .h

Done.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor_cc.h (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:10: #include "base/memory/scoped_ptr.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> necessary?

Gone.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:11: #include "base/memory/ref_counted.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> necessary?

Gone.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:17: #include
"third_party/WebKit/Source/WebKit/chromium/public/WebLayerTreeViewClient.h"
On 2011/10/18 15:28:26, jonathan.backer wrote:
> nit: 80 column limit?

It's ok for includes (thankfully), as per
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Line_Length

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:50: static void TerminateThread();
On 2011/10/18 15:28:26, jonathan.backer wrote:
> I don't see where these are called.

They are not yet called, waiting on another webkit patch to land. They will be
called from aura::Desktop initialization/shutdown.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor_cc.h:53: virtual void OnWidgetSizeChanged()
OVERRIDE;
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> // Compositor

Done.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc
File ui/gfx/compositor/layer.cc (right):

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:1: // Copyright (c) 2011 The Chromium Authors. All
rights reserved.
On 2011/10/18 15:40:40, Ben Goodger (Google) wrote:
> Seems like we'd need to extract some of this code as a base then, since we
have
> lots of conversion/utility functions here too.

If we were to support 2 compositors in the long run, I would look at
refactoring, but to do it properly is significant:
- making essentially all of layer's public API virtual, and giving hooks for
subclasses to do extra work
- move some of the logic into external reusable functions
- rework some tests that rely on inheriting from Layer

Since the 2 compositor case is only for a short period, I don't think it's a
good use of our time to do  that - the ifdefs can disappear within a 1-2 month
timeframe. So unless you feel very strongly, I'd rather not spend time on this.

I changed into #ifdefs making this more readable.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:66: if (!web_layer_.isNull())
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> I'd actually rather see #ifdefs in this file... given that when we flip the
> switch we probably won't want all these null checks.

Done. My initial thought was that we could support 2 compositors with a run-time
flag, but I think it's misguided, so I reverted to #ifdefs.

http://codereview.chromium.org/8222028/diff/5001/ui/gfx/compositor/layer.cc#n...
ui/gfx/compositor/layer.cc:327: void Layer::RecomputeDrawsContent() {
On 2011/10/16 22:39:51, Ben Goodger (Google) wrote:
> order in .cc should match .h

Done.

[Ben Goodger (Google), 2011-10-19 18:13:43]

Cool. LGTM from my perspective.

[jonathan.backer, 2011-10-19 19:40:39]

On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
> Cool. LGTM from my perspective.

Doesn't build for me with use_aura=1 and use_webkit_compositor=1. Failing on the
image transport. I'm guessing that I also need
http://codereview.chromium.org/8307001/

BTW, I tried an earlier version of this with component=shared_library build and
it wouldn't link. Have you tried this? I think it's critical from a developer
perspective.

[piman, 2011-10-19 20:31:32]

On Wed, Oct 19, 2011 at 12:40 PM, <backer@chromium.org> wrote:

> On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
>
>> Cool. LGTM from my perspective.
>>
>
> Doesn't build for me with use_aura=1 and use_webkit_compositor=1. Failing
> on the
> image transport. I'm guessing that I also need
>
http://codereview.chromium.**org/8307001/<http://codereview.chromium.org/8307...


That's correct. Patch probably wouldn't apply without it.


> BTW, I tried an earlier version of this with component=shared_library build
> and
> it wouldn't link. Have you tried this? I think it's critical from a
> developer
> perspective.
>

Have not tried, I'll double check. We have no trybot/buildbot for that
configuration...


>
>
http://codereview.chromium.**org/8222028/<http://codereview.chromium.org/8222...
>

[piman, 2011-10-19 20:32:43]

On Wed, Oct 19, 2011 at 1:31 PM, Antoine Labour <piman@chromium.org> wrote:

>
>
> On Wed, Oct 19, 2011 at 12:40 PM, <backer@chromium.org> wrote:
>
>> On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
>>
>>> Cool. LGTM from my perspective.
>>>
>>
>> Doesn't build for me with use_aura=1 and use_webkit_compositor=1. Failing
>> on the
>> image transport. I'm guessing that I also need
>>
http://codereview.chromium.**org/8307001/<http://codereview.chromium.org/8307...
>
>
> That's correct. Patch probably wouldn't apply without it.
>

Wait, sorry. other way around.
This version should work.


>
>
>> BTW, I tried an earlier version of this with component=shared_library
>> build and
>> it wouldn't link. Have you tried this? I think it's critical from a
>> developer
>> perspective.
>>
>
> Have not tried, I'll double check. We have no trybot/buildbot for that
> configuration...
>
>
>>
>>
http://codereview.chromium.**org/8222028/<http://codereview.chromium.org/8222...
>>
>
>

[piman, 2011-10-19 23:38:54]

On 2011/10/19 20:32:43, piman wrote:
> On Wed, Oct 19, 2011 at 1:31 PM, Antoine Labour <mailto:piman@chromium.org>
wrote:
> 
> >
> >
> > On Wed, Oct 19, 2011 at 12:40 PM, <mailto:backer@chromium.org> wrote:
> >
> >> On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
> >>
> >>> Cool. LGTM from my perspective.
> >>>
> >>
> >> Doesn't build for me with use_aura=1 and use_webkit_compositor=1. Failing
> >> on the
> >> image transport. I'm guessing that I also need
> >>
>
http://codereview.chromium.**org/8307001/%3Chttp://codereview.chromium.org/83...>
> >
> >
> > That's correct. Patch probably wouldn't apply without it.
> >
> 
> Wait, sorry. other way around.
> This version should work.
> 
> 
> >
> >
> >> BTW, I tried an earlier version of this with component=shared_library
> >> build and
> >> it wouldn't link. Have you tried this? I think it's critical from a
> >> developer
> >> perspective.
> >>
> >
> > Have not tried, I'll double check. We have no trybot/buildbot for that
> > configuration...

The latest patch, combined with https://bugs.webkit.org/show_bug.cgi?id=70440
makes it link in the component build.
However it doesn't run because there is a horrible issue with ANGLE and the
component build:
- a part of ANGLE ends up (statically) linked in both libwebkit.so and
libcompositor.so (through webkit_gpu)
- ANGLE leaks weak symbols because of stl template instantiation, which have
"vague" linkage
- because these symbol leak, the code jumps arbitrarily across the 2 versions of
the ANGLE static lib, that use different globals, leading to incorrect behavior.

Bottom line, it doesn't work. Options are:
- look into getting ANGLE to build as a component
- duplicate WebGraphicsContext3DInProcessImpl into a version that doesn't need
ANGLE, and use that one for CompositorCC
- wait until we use command buffers / out-of-process GL, at which point we won't
need WebGraphicsContext3DInProcessImpl any more

Note that all this doesn't prevent us from landing this patch, since the
problematic dependency should only come up with 'use_webkit_compositor=1' which
is not on by default.


> >
> >
> >>
> >>
>
http://codereview.chromium.**org/8222028/%3Chttp://codereview.chromium.org/82...>
> >>
> >
> >

[Ben Goodger (Google), 2011-10-20 01:07:37]

I would be inclined not to block development of something that is off by
default. Note that the component build issues will probably have to be
resolved before it can turn on by default.

-Ben

On Wed, Oct 19, 2011 at 4:38 PM, <piman@chromium.org> wrote:

> On 2011/10/19 20:32:43, piman wrote:
>
>> On Wed, Oct 19, 2011 at 1:31 PM, Antoine Labour <mailto:
>> piman@chromium.org>
>>
> wrote:
>
>
>  >
>> >
>> > On Wed, Oct 19, 2011 at 12:40 PM, <mailto:backer@chromium.org> wrote:
>> >
>> >> On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
>> >>
>> >>> Cool. LGTM from my perspective.
>> >>>
>> >>
>> >> Doesn't build for me with use_aura=1 and use_webkit_compositor=1.
>> Failing
>> >> on the
>> >> image transport. I'm guessing that I also need
>> >>
>>
>
> http://codereview.chromium.****org/8307001/%3Chttp://coderevi**
> ew.chromium.org/8307001/ <http://codereview.chromium.org/8307001/>>
>
>  >
>> >
>> > That's correct. Patch probably wouldn't apply without it.
>> >
>>
>
>  Wait, sorry. other way around.
>> This version should work.
>>
>
>
>  >
>> >
>> >> BTW, I tried an earlier version of this with component=shared_library
>> >> build and
>> >> it wouldn't link. Have you tried this? I think it's critical from a
>> >> developer
>> >> perspective.
>> >>
>> >
>> > Have not tried, I'll double check. We have no trybot/buildbot for that
>> > configuration...
>>
>
> The latest patch, combined with https://bugs.webkit.org/show_**
> bug.cgi?id=70440 <https://bugs.webkit.org/show_bug.cgi?id=70440>
> makes it link in the component build.
> However it doesn't run because there is a horrible issue with ANGLE and the
> component build:
> - a part of ANGLE ends up (statically) linked in both libwebkit.so and
> libcompositor.so (through webkit_gpu)
> - ANGLE leaks weak symbols because of stl template instantiation, which
> have
> "vague" linkage
> - because these symbol leak, the code jumps arbitrarily across the 2
> versions of
> the ANGLE static lib, that use different globals, leading to incorrect
> behavior.
>
> Bottom line, it doesn't work. Options are:
> - look into getting ANGLE to build as a component
> - duplicate WebGraphicsContext3DInProcessI**mpl into a version that
> doesn't need
> ANGLE, and use that one for CompositorCC
> - wait until we use command buffers / out-of-process GL, at which point we
> won't
> need WebGraphicsContext3DInProcessI**mpl any more
>
> Note that all this doesn't prevent us from landing this patch, since the
> problematic dependency should only come up with 'use_webkit_compositor=1'
> which
> is not on by default.
>
>
>  >
>> >
>> >>
>> >>
>>
>
> http://codereview.chromium.****org/8222028/%3Chttp://coderevi**
> ew.chromium.org/8222028/ <http://codereview.chromium.org/8222028/>>
>
>> >>
>> >
>> >
>>
>
>
>
>
http://codereview.chromium.**org/8222028/<http://codereview.chromium.org/8222...
>

[piman, 2011-10-20 01:10:23]

On Wed, Oct 19, 2011 at 6:07 PM, Ben Goodger (Google) <ben@chromium.org>wrote:

> I would be inclined not to block development of something that is off by
> default. Note that the component build issues will probably have to be
> resolved before it can turn on by default.


Agreed. I've been looking at a way to get ANGLE to build as a component, and
had success with. I'll try to run this by the ANGLE people.

Antoine


>
> -Ben
>
>
> On Wed, Oct 19, 2011 at 4:38 PM, <piman@chromium.org> wrote:
>
>> On 2011/10/19 20:32:43, piman wrote:
>>
>>> On Wed, Oct 19, 2011 at 1:31 PM, Antoine Labour <mailto:
>>> piman@chromium.org>
>>>
>> wrote:
>>
>>
>>  >
>>> >
>>> > On Wed, Oct 19, 2011 at 12:40 PM, <mailto:backer@chromium.org> wrote:
>>> >
>>> >> On 2011/10/19 18:13:43, Ben Goodger (Google) wrote:
>>> >>
>>> >>> Cool. LGTM from my perspective.
>>> >>>
>>> >>
>>> >> Doesn't build for me with use_aura=1 and use_webkit_compositor=1.
>>> Failing
>>> >> on the
>>> >> image transport. I'm guessing that I also need
>>> >>
>>>
>>
>> http://codereview.chromium.****org/8307001/%3Chttp://coderevi**
>> ew.chromium.org/8307001/ <http://codereview.chromium.org/8307001/>>
>>
>>  >
>>> >
>>> > That's correct. Patch probably wouldn't apply without it.
>>> >
>>>
>>
>>  Wait, sorry. other way around.
>>> This version should work.
>>>
>>
>>
>>  >
>>> >
>>> >> BTW, I tried an earlier version of this with component=shared_library
>>> >> build and
>>> >> it wouldn't link. Have you tried this? I think it's critical from a
>>> >> developer
>>> >> perspective.
>>> >>
>>> >
>>> > Have not tried, I'll double check. We have no trybot/buildbot for that
>>> > configuration...
>>>
>>
>> The latest patch, combined with https://bugs.webkit.org/show_**
>> bug.cgi?id=70440 <https://bugs.webkit.org/show_bug.cgi?id=70440>
>> makes it link in the component build.
>> However it doesn't run because there is a horrible issue with ANGLE and
>> the
>> component build:
>> - a part of ANGLE ends up (statically) linked in both libwebkit.so and
>> libcompositor.so (through webkit_gpu)
>> - ANGLE leaks weak symbols because of stl template instantiation, which
>> have
>> "vague" linkage
>> - because these symbol leak, the code jumps arbitrarily across the 2
>> versions of
>> the ANGLE static lib, that use different globals, leading to incorrect
>> behavior.
>>
>> Bottom line, it doesn't work. Options are:
>> - look into getting ANGLE to build as a component
>> - duplicate WebGraphicsContext3DInProcessI**mpl into a version that
>> doesn't need
>> ANGLE, and use that one for CompositorCC
>> - wait until we use command buffers / out-of-process GL, at which point we
>> won't
>> need WebGraphicsContext3DInProcessI**mpl any more
>>
>> Note that all this doesn't prevent us from landing this patch, since the
>> problematic dependency should only come up with 'use_webkit_compositor=1'
>> which
>> is not on by default.
>>
>>
>>  >
>>> >
>>> >>
>>> >>
>>>
>>
>> http://codereview.chromium.****org/8222028/%3Chttp://coderevi**
>> ew.chromium.org/8222028/ <http://codereview.chromium.org/8222028/>>
>>
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>>
http://codereview.chromium.**org/8222028/<http://codereview.chromium.org/8222...
>>
>
>

[jonathan.backer, 2011-10-20 13:06:15]

LGTM

I think once the WebKit export gets resolved, we'll have the
component=shared_library build working on Linux.

[commit-bot: I haz the power, 2011-10-20 16:48:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/piman@chromium.org/8222028/23007

[commit-bot: I haz the power, 2011-10-20 20:06:29]

The commit queue went berserk retrying too often for a
seemingly flaky test. Builder is win_rel, revision is 106552, job name
was 8222028-23007 (retry) (retry) (retry) (retry).

[commit-bot: I haz the power, 2011-10-20 20:51:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/piman@chromium.org/8222028/23007

[commit-bot: I haz the power, 2011-10-20 22:39:46]

Change committed as 106606

[commit-bot: I haz the power, 2011-10-21 22:14:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/piman@chromium.org/8222028/38029

[commit-bot: I haz the power, 2011-10-22 00:32:48]

Change committed as 106814