ozone: Initialize a subsystem only if necessary.

ozone: Initialize a subsystem only if necessary.

Some of the ozone subsystems don't need to be initialized in the GPU
process (e.g. events). So let the ozone-platform know what process the
platform is being initialized for, and initialize only the subsystems
that make sense for that process.

The changes include:
 * Remove SetInstance() from EventFactoryOzone, SurfaceFactoryOzone and
   CursorFactoryOzone. Instead, set the instance from the constructor.
 * Require the platforms to provide one explicit constructor for the UI
   and GPU processes through the OzonePlatform interface.
 * Do not initialize any of the sub-systems in InitializeGPU() in all
   platforms.
 * Move the initialization of ozone-platform into aura::Env::Init.
 * Move the creation of udev-monitor in DeviceManagerUdev from the
   constructor to ScanDevices(), since it needs the message-loop, and the
   message-loop is constructed later.
 * Update EventFactoryEvdev to set the ui_task_runner_ from
   OnDispatcherListChanged(), since this too is created before the
   message-loop.

BUG=361137
R=piman@chromium.org
TBR=spang@chromium.org

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

[sadrul, 2014-05-15 19:00:50]

I am returning NULL from all CreateOzonePlatform*ForGPU() implementations for
now. This crashes the GPU process (the fix is trivial: check that the platform
was initialized correctly before trying to access SurfaceFactoryOzone in
InitializeStaticGLBindings()), but the caca/test platforms do work correctly (I
have not tested egltest (it fails to load libeglplatform_shim.so.1), or dri
implementations yet).

[kalyank, 2014-05-15 19:21:45]

https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc
File ui/ozone/ozone_platform.cc (right):

https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc#n...
ui/ozone/ozone_platform.cc:64: ui::InputMethodContextFactoryOzone::SetInstance(
shouldn't we do the same with this. It should be set only in case of UI ?

[sadrul, 2014-05-15 19:27:24]

https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc
File ui/ozone/ozone_platform.cc (right):

https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc#n...
ui/ozone/ozone_platform.cc:64: ui::InputMethodContextFactoryOzone::SetInstance(
On 2014/05/15 19:21:45, kalyank wrote:
> shouldn't we do the same with this. It should be set only in case of UI ?

I wanted to, but the SetInstance() here is for the non-ozone
LinuxInputMethodContextFactory. So I left that alone for the moment. I do want
to revisit this soon though (I am not convinced we actually need the
InputMethodContextFactoryOzone at all. The ozone platforms should just
create/set a LinuxInputMethodContextFactory instance, and that should be
sufficient).

[spang, 2014-05-15 19:53:56]

On 2014/05/15 19:27:24, sadrul wrote:
> https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc
> File ui/ozone/ozone_platform.cc (right):
> 
>
https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc#n...
> ui/ozone/ozone_platform.cc:64:
ui::InputMethodContextFactoryOzone::SetInstance(
> On 2014/05/15 19:21:45, kalyank wrote:
> > shouldn't we do the same with this. It should be set only in case of UI ?
> 
> I wanted to, but the SetInstance() here is for the non-ozone
> LinuxInputMethodContextFactory. So I left that alone for the moment. I do want
> to revisit this soon though (I am not convinced we actually need the
> InputMethodContextFactoryOzone at all. The ozone platforms should just
> create/set a LinuxInputMethodContextFactory instance, and that should be
> sufficient).

Why do we need a second entry point for the platform?

What about something like this:

class OzonePlatform {
  virtual void InitializeForUI() = 0;

  virtual void InitializeForGPU() = 0;

  static void InitializeForUI() {
    if (!instance_) instance_ = CreatePlatform();
    return instance_->InitializeForUI();
  }

  static void InitializeForGPU() {
    if (!instance_) instance_ = CreatePlatform();
    return instance_->InitializeForGPU();
  }
};

We should do something that is compatible with doing GL in process. Targets like
aura_demo do that.

[sadrul, 2014-05-15 20:23:25]

On 2014/05/15 19:53:56, spang wrote:
> On 2014/05/15 19:27:24, sadrul wrote:
> > https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc
> > File ui/ozone/ozone_platform.cc (right):
> > 
> >
>
https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc#n...
> > ui/ozone/ozone_platform.cc:64:
> ui::InputMethodContextFactoryOzone::SetInstance(
> > On 2014/05/15 19:21:45, kalyank wrote:
> > > shouldn't we do the same with this. It should be set only in case of UI ?
> > 
> > I wanted to, but the SetInstance() here is for the non-ozone
> > LinuxInputMethodContextFactory. So I left that alone for the moment. I do
want
> > to revisit this soon though (I am not convinced we actually need the
> > InputMethodContextFactoryOzone at all. The ozone platforms should just
> > create/set a LinuxInputMethodContextFactory instance, and that should be
> > sufficient).
> 
> Why do we need a second entry point for the platform?
> 
> What about something like this:
> 
> class OzonePlatform {
>   virtual void InitializeForUI() = 0;
> 
>   virtual void InitializeForGPU() = 0;
> 
>   static void InitializeForUI() {
>     if (!instance_) instance_ = CreatePlatform();
>     return instance_->InitializeForUI();
>   }
> 
>   static void InitializeForGPU() {
>     if (!instance_) instance_ = CreatePlatform();
>     return instance_->InitializeForGPU();
>   }
> };

That would work too. The current implementations always create the
event-factories, and I feel like that is slightly cleaner than creating them
on-demand in scoped_ptr<>s. But what you suggest works too. I will make this
change.

> 
> We should do something that is compatible with doing GL in process. Targets
like
> aura_demo do that.

[sadrul, 2014-05-15 20:55:09]

On 2014/05/15 20:23:25, sadrul wrote:
> On 2014/05/15 19:53:56, spang wrote:
> > On 2014/05/15 19:27:24, sadrul wrote:
> > >
https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc
> > > File ui/ozone/ozone_platform.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/291473002/diff/1/ui/ozone/ozone_platform.cc#n...
> > > ui/ozone/ozone_platform.cc:64:
> > ui::InputMethodContextFactoryOzone::SetInstance(
> > > On 2014/05/15 19:21:45, kalyank wrote:
> > > > shouldn't we do the same with this. It should be set only in case of UI
?
> > > 
> > > I wanted to, but the SetInstance() here is for the non-ozone
> > > LinuxInputMethodContextFactory. So I left that alone for the moment. I do
> want
> > > to revisit this soon though (I am not convinced we actually need the
> > > InputMethodContextFactoryOzone at all. The ozone platforms should just
> > > create/set a LinuxInputMethodContextFactory instance, and that should be
> > > sufficient).
> > 
> > Why do we need a second entry point for the platform?
> > 
> > What about something like this:
> > 
> > class OzonePlatform {
> >   virtual void InitializeForUI() = 0;
> > 
> >   virtual void InitializeForGPU() = 0;
> > 
> >   static void InitializeForUI() {
> >     if (!instance_) instance_ = CreatePlatform();
> >     return instance_->InitializeForUI();
> >   }
> > 
> >   static void InitializeForGPU() {
> >     if (!instance_) instance_ = CreatePlatform();
> >     return instance_->InitializeForGPU();
> >   }
> > };
> 
> That would work too. The current implementations always create the
> event-factories, and I feel like that is slightly cleaner than creating them
> on-demand in scoped_ptr<>s. But what you suggest works too. I will make this
> change.

Done.

[sadrul, 2014-05-15 20:56:07]

+piman@ for changes in content/browser/ and ui/gl/

[piman, 2014-05-15 21:35:54]

LGTM. Keep in mind that in some configurations (e.g. tests) both "GPU" and "UI"
can be the same process, and so both InitializeForUI and InitializeForGPU can be
called, but it looks like this should still work correctly in this case.

[sadrul, 2014-05-16 02:28:15]

I have addressed spang's concern in the CL. Landing this to unblock
https://codereview.chromium.org/285303004/ (and another cleanup CL for
input-method-context-factory).

[sadrul, 2014-05-16 02:29:32]

Committed patchset #4 manually as r270903 (presubmit successful).