Add export directives needed by Chromium WM project.

Add export directives needed by Chromium WM project.

BUG=124444

[piman, 2013-02-28 17:40:09]

+jam, content API gatekeeper.

We have a general policy in Chrome that the clients of content should only go
through the content public API (in content/public). In a way, it seems that we
have an even stronger case for this if the client is in a separate repo.

Should we expose what you need in the content API? Which parts do you need
exactly?

[reveman, 2013-02-28 19:17:06]

On 2013/02/28 17:40:09, piman wrote:
> +jam, content API gatekeeper.
> 
> We have a general policy in Chrome that the clients of content should only go
> through the content public API (in content/public). In a way, it seems that we
> have an even stronger case for this if the client is in a separate repo.
> 
> Should we expose what you need in the content API? Which parts do you need
> exactly?

Makes sense. Here's the code that consumes this:
https://codereview.chromium.org/11485006/diff/24007/wm/gpu/foreign_window_tex...

It's using BrowserGpuChannelHostFactory::CreateImage/DeleteImage to create
images that can be bound to textures.

It's using ImageTransportFactory::GetInstance() and the observers interface that
class provides to be notified of lost context situations.

It's using ImageTransportFactory::GetGLHelper() and GLHelper::context() to get
the appropriated WebGraphicsContext3D to be used for texture bindings.

[piman, 2013-03-01 02:14:16]

On Thu, Feb 28, 2013 at 11:17 AM, <reveman@chromium.org> wrote:

> On 2013/02/28 17:40:09, piman wrote:
>
>> +jam, content API gatekeeper.
>>
>
>  We have a general policy in Chrome that the clients of content should
>> only go
>> through the content public API (in content/public). In a way, it seems
>> that we
>> have an even stronger case for this if the client is in a separate repo.
>>
>
>  Should we expose what you need in the content API? Which parts do you need
>> exactly?
>>
>
> Makes sense. Here's the code that consumes this:
> https://codereview.chromium.**org/11485006/diff/24007/wm/**
>
gpu/foreign_window_texture_**factory.cc<https://codereview.chromium.org/11485006/diff/24007/wm/gpu/foreign_window_texture_factory.cc>
>
> It's using BrowserGpuChannelHostFactory::**CreateImage/DeleteImage to
> create
> images that can be bound to textures.
>
> It's using ImageTransportFactory::**GetInstance() and the observers
> interface that
> class provides to be notified of lost context situations.
>
> It's using ImageTransportFactory::**GetGLHelper() and GLHelper::context()
> to get
> the appropriated WebGraphicsContext3D to be used for texture bindings.
>

So yeah, it seems we could do a minimal singleton API, with
CreateImage/DeleteImage/GetSharedContext/SetLostReourcesCallback or
something along these lines. It would only be implemented on Aura, probably
by the ImageTransportFactory.

Maybe work with jam@ to see if that's ok to add on the content API.

Antoine


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

[jam, 2013-03-01 19:00:49]

On 2013/03/01 02:14:16, piman wrote:
> On Thu, Feb 28, 2013 at 11:17 AM, <mailto:reveman@chromium.org> wrote:
> 
> > On 2013/02/28 17:40:09, piman wrote:
> >
> >> +jam, content API gatekeeper.
> >>
> >
> >  We have a general policy in Chrome that the clients of content should
> >> only go
> >> through the content public API (in content/public). In a way, it seems
> >> that we
> >> have an even stronger case for this if the client is in a separate repo.
> >>
> >
> >  Should we expose what you need in the content API? Which parts do you need
> >> exactly?
> >>
> >
> > Makes sense. Here's the code that consumes this:
> > https://codereview.chromium.**org/11485006/diff/24007/wm/**
> >
>
gpu/foreign_window_texture_**factory.cc<https://codereview.chromium.org/11485006/diff/24007/wm/gpu/foreign_window_texture_factory.cc>
> >
> > It's using BrowserGpuChannelHostFactory::**CreateImage/DeleteImage to
> > create
> > images that can be bound to textures.
> >
> > It's using ImageTransportFactory::**GetInstance() and the observers
> > interface that
> > class provides to be notified of lost context situations.
> >
> > It's using ImageTransportFactory::**GetGLHelper() and GLHelper::context()
> > to get
> > the appropriated WebGraphicsContext3D to be used for texture bindings.
> >
> 
> So yeah, it seems we could do a minimal singleton API, with
> CreateImage/DeleteImage/GetSharedContext/SetLostReourcesCallback or
> something along these lines. It would only be implemented on Aura, probably
> by the ImageTransportFactory.
> 
> Maybe work with jam@ to see if that's ok to add on the content API.
> 
> Antoine

yeah your code shouldn't use any content code other than content/public.

can you give a proposal for a public api per Antoine's suggestion and we can
discuss from there?

in your other change that you linked to, make sure that DEPS only allows
content/public and not content