ozone: Add OzoneWindowFactory & OzoneWindow

ozone: Add OzoneWindowFactory & OzoneWindow

This adds window a creation API to ozone & adds a new OzoneWindow
interface for window operations.

The OzoneWindow gets various window-related methods that were previously
on SurfaceFactoryOzone, CursorFactoryOzone, & EventFactoryOzone. All of
those functions used to take an intptr_t AcceleratedWidget, and were
expected to coordinate behind the scenes in order to function. This
centralizes all window operations in one place.

The window is owned by WindowTreeHostOzone so that it is cleaned up
correctly when we destroy the host.

TEST=ui_unittests, content_shell --ozone-platform={test,dri}
BUG=none

[spang, 2014-03-20 17:16:37]

OzoneWindow is probably now the same object as in sadrul's proposal.

Maybe we should rename it to PlatformWindow & check in at ui/platform? So 2
phases:

1. Check in the interface & use with ozone.

2. Convert other platforms to use it (when ready to do so).

I am willing to promise to do (2) once we're ready.

Sadrul?

[spang, 2014-03-20 17:22:04]

This depends on https://codereview.chromium.org/205433002/

[rjkroege, 2014-03-24 16:11:51]

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
File ui/ozone/window/ozone_window.h (right):

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
this needs to be coupled to the backing Display in some fashion. I need to think
about how. dnicora@: what do you think?

[spang, 2014-03-24 18:15:29]

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
File ui/ozone/window/ozone_window.h (right):

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
On 2014/03/24 16:11:51, rjkroege wrote:
> this needs to be coupled to the backing Display in some fashion. I need to
think
> about how. dnicora@: what do you think?


Yes. I think this must happen behind the scenes in WindowFactoryOzone though:

- WindowFactoryOzone gets the initial screen bounds in CreateWindow()
- WindowFactoryOzone finds the right display from screen bounds
- WindowFactoryOzone passes the platform-internal display object to the
platform-internal window constructor

[rjkroege, 2014-03-24 20:08:59]

On 2014/03/24 18:15:29, spang wrote:
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> File ui/ozone/window/ozone_window.h (right):
> 
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> On 2014/03/24 16:11:51, rjkroege wrote:
> > this needs to be coupled to the backing Display in some fashion. I need to
> think
> > about how. dnicora@: what do you think?
> 
> 
> Yes. I think this must happen behind the scenes in WindowFactoryOzone though:

Hm. I'm not convinced.

> 
> - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> - WindowFactoryOzone finds the right display from screen bounds

what if you have two identical monitors?

> - WindowFactoryOzone passes the platform-internal display object to the
> platform-internal window constructor

[dnicoara, 2014-03-24 21:04:26]

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
File ui/ozone/window/ozone_window.h (right):

https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
On 2014/03/24 18:15:29, spang wrote:
> On 2014/03/24 16:11:51, rjkroege wrote:
> > this needs to be coupled to the backing Display in some fashion. I need to
> think
> > about how. dnicora@: what do you think?
> 
> 
> Yes. I think this must happen behind the scenes in WindowFactoryOzone though:
> 
> - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> - WindowFactoryOzone finds the right display from screen bounds
> - WindowFactoryOzone passes the platform-internal display object to the
> platform-internal window constructor

Having the coupling behind the scenes should be fine. From a configuration
perspective we'll likely need to know which OzoneWindow belongs to which
display, though we'll have that information when creating the OzoneWindow. From
a WindowFactoryOzone perspective, we'll likely need to pass in a gfx::Display or
maybe the display id in order to get the correct mapping.

[spang, 2014-03-24 23:59:00]

On 2014/03/24 20:08:59, rjkroege wrote:
> On 2014/03/24 18:15:29, spang wrote:
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > File ui/ozone/window/ozone_window.h (right):
> > 
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> > On 2014/03/24 16:11:51, rjkroege wrote:
> > > this needs to be coupled to the backing Display in some fashion. I need to
> > think
> > > about how. dnicora@: what do you think?
> > 
> > 
> > Yes. I think this must happen behind the scenes in WindowFactoryOzone
though:
> 
> Hm. I'm not convinced.
> 
> > 
> > - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> > - WindowFactoryOzone finds the right display from screen bounds
> 
> what if you have two identical monitors?
> 

Don't the windows exist in "screen" space? So you find the display by looking at
which display it sits on in screen space. Two identical monitors surely have
different bounds in the screen.

I imagine it's possible to reparent windows to different displays by calling
SetBounds, right?


> > - WindowFactoryOzone passes the platform-internal display object to the
> > platform-internal window constructor

[spang, 2014-03-25 00:04:38]

On 2014/03/24 23:59:00, spang wrote:
> On 2014/03/24 20:08:59, rjkroege wrote:
> > On 2014/03/24 18:15:29, spang wrote:
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > > File ui/ozone/window/ozone_window.h (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> > > On 2014/03/24 16:11:51, rjkroege wrote:
> > > > this needs to be coupled to the backing Display in some fashion. I need
to
> > > think
> > > > about how. dnicora@: what do you think?
> > > 
> > > 
> > > Yes. I think this must happen behind the scenes in WindowFactoryOzone
> though:
> > 
> > Hm. I'm not convinced.
> > 
> > > 
> > > - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> > > - WindowFactoryOzone finds the right display from screen bounds
> > 
> > what if you have two identical monitors?
> > 
> 
> Don't the windows exist in "screen" space? So you find the display by looking
at
> which display it sits on in screen space. Two identical monitors surely have
> different bounds in the screen.
>

Screen::GetDisplayNearestWindow yeah?
 
> I imagine it's possible to reparent windows to different displays by calling
> SetBounds, right?
> 
> 
> > > - WindowFactoryOzone passes the platform-internal display object to the
> > > platform-internal window constructor

[sadrul, 2014-03-25 22:49:53]

On 2014/03/25 00:04:38, spang wrote:
> On 2014/03/24 23:59:00, spang wrote:
> > On 2014/03/24 20:08:59, rjkroege wrote:
> > > On 2014/03/24 18:15:29, spang wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > > > File ui/ozone/window/ozone_window.h (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > > > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> > > > On 2014/03/24 16:11:51, rjkroege wrote:
> > > > > this needs to be coupled to the backing Display in some fashion. I
need
> to
> > > > think
> > > > > about how. dnicora@: what do you think?
> > > > 
> > > > 
> > > > Yes. I think this must happen behind the scenes in WindowFactoryOzone
> > though:
> > > 
> > > Hm. I'm not convinced.
> > > 
> > > > 
> > > > - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> > > > - WindowFactoryOzone finds the right display from screen bounds
> > > 
> > > what if you have two identical monitors?
> > > 
> > 
> > Don't the windows exist in "screen" space? So you find the display by
looking
> at
> > which display it sits on in screen space. Two identical monitors surely have
> > different bounds in the screen.
> >
> 
> Screen::GetDisplayNearestWindow yeah?

This apparently doesn't work for mirror modes, where there are two displays, and
both are in the same coordinate space. Yufeng has been working in related areas
for the touch-calibration patch. He might have more details.

[spang, 2014-03-26 14:25:32]

On 2014/03/25 22:49:53, sadrul wrote:
> On 2014/03/25 00:04:38, spang wrote:
> > On 2014/03/24 23:59:00, spang wrote:
> > > On 2014/03/24 20:08:59, rjkroege wrote:
> > > > On 2014/03/24 18:15:29, spang wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > > > > File ui/ozone/window/ozone_window.h (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > > > > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> > > > > On 2014/03/24 16:11:51, rjkroege wrote:
> > > > > > this needs to be coupled to the backing Display in some fashion. I
> need
> > to
> > > > > think
> > > > > > about how. dnicora@: what do you think?
> > > > > 
> > > > > 
> > > > > Yes. I think this must happen behind the scenes in WindowFactoryOzone
> > > though:
> > > > 
> > > > Hm. I'm not convinced.
> > > > 
> > > > > 
> > > > > - WindowFactoryOzone gets the initial screen bounds in CreateWindow()
> > > > > - WindowFactoryOzone finds the right display from screen bounds
> > > > 
> > > > what if you have two identical monitors?
> > > > 
> > > 
> > > Don't the windows exist in "screen" space? So you find the display by
> looking
> > at
> > > which display it sits on in screen space. Two identical monitors surely
have
> > > different bounds in the screen.
> > >
> > 
> > Screen::GetDisplayNearestWindow yeah?
> 
> This apparently doesn't work for mirror modes, where there are two displays,
and
> both are in the same coordinate space. Yufeng has been working in related
areas
> for the touch-calibration patch. He might have more details.

For mirroring, the window is on both displays, right? Shouldn't you find both
displays?

[rjkroege, 2014-03-31 15:45:40]

On 2014/03/26 14:25:32, spang wrote:
> On 2014/03/25 22:49:53, sadrul wrote:
> > On 2014/03/25 00:04:38, spang wrote:
> > > On 2014/03/24 23:59:00, spang wrote:
> > > > On 2014/03/24 20:08:59, rjkroege wrote:
> > > > > On 2014/03/24 18:15:29, spang wrote:
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > > > > > File ui/ozone/window/ozone_window.h (right):
> > > > > > 
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > > > > > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow {
> > > > > > On 2014/03/24 16:11:51, rjkroege wrote:
> > > > > > > this needs to be coupled to the backing Display in some fashion. I
> > need
> > > to
> > > > > > think
> > > > > > > about how. dnicora@: what do you think?
> > > > > > 
> > > > > > 
> > > > > > Yes. I think this must happen behind the scenes in
WindowFactoryOzone
> > > > though:
> > > > > 
> > > > > Hm. I'm not convinced.
> > > > > 
> > > > > > 
> > > > > > - WindowFactoryOzone gets the initial screen bounds in
CreateWindow()
> > > > > > - WindowFactoryOzone finds the right display from screen bounds
> > > > > 
> > > > > what if you have two identical monitors?
> > > > > 
> > > > 
> > > > Don't the windows exist in "screen" space? So you find the display by
> > looking
> > > at
> > > > which display it sits on in screen space. Two identical monitors surely
> have
> > > > different bounds in the screen.
> > > >
> > > 
> > > Screen::GetDisplayNearestWindow yeah?
> > 
> > This apparently doesn't work for mirror modes, where there are two displays,
> and
> > both are in the same coordinate space. Yufeng has been working in related
> areas
> > for the touch-calibration patch. He might have more details.
> 
> For mirroring, the window is on both displays, right? Shouldn't you find both
> displays?

hardware-assisted mirroring or software-enabled mirroring?

I've lost track of the details here. We have screens, displays, windows, SFOz,
SOz. Draw me a picture?

[spang, 2014-03-31 18:52:02]

On 2014/03/31 15:45:40, rjkroege wrote:
> On 2014/03/26 14:25:32, spang wrote:
> > On 2014/03/25 22:49:53, sadrul wrote:
> > > On 2014/03/25 00:04:38, spang wrote:
> > > > On 2014/03/24 23:59:00, spang wrote:
> > > > > On 2014/03/24 20:08:59, rjkroege wrote:
> > > > > > On 2014/03/24 18:15:29, spang wrote:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window.h
> > > > > > > File ui/ozone/window/ozone_window.h (right):
> > > > > > > 
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/205433005/diff/1/ui/ozone/window/ozone_window...
> > > > > > > ui/ozone/window/ozone_window.h:35: class OZONE_EXPORT OzoneWindow
{
> > > > > > > On 2014/03/24 16:11:51, rjkroege wrote:
> > > > > > > > this needs to be coupled to the backing Display in some fashion.
I
> > > need
> > > > to
> > > > > > > think
> > > > > > > > about how. dnicora@: what do you think?
> > > > > > > 
> > > > > > > 
> > > > > > > Yes. I think this must happen behind the scenes in
> WindowFactoryOzone
> > > > > though:
> > > > > > 
> > > > > > Hm. I'm not convinced.
> > > > > > 
> > > > > > > 
> > > > > > > - WindowFactoryOzone gets the initial screen bounds in
> CreateWindow()
> > > > > > > - WindowFactoryOzone finds the right display from screen bounds
> > > > > > 
> > > > > > what if you have two identical monitors?
> > > > > > 
> > > > > 
> > > > > Don't the windows exist in "screen" space? So you find the display by
> > > looking
> > > > at
> > > > > which display it sits on in screen space. Two identical monitors
surely
> > have
> > > > > different bounds in the screen.
> > > > >
> > > > 
> > > > Screen::GetDisplayNearestWindow yeah?
> > > 
> > > This apparently doesn't work for mirror modes, where there are two
displays,
> > and
> > > both are in the same coordinate space. Yufeng has been working in related
> > areas
> > > for the touch-calibration patch. He might have more details.
> > 
> > For mirroring, the window is on both displays, right? Shouldn't you find
both
> > displays?
> 
> hardware-assisted mirroring or software-enabled mirroring?
> 
> I've lost track of the details here. We have screens, displays, windows, SFOz,
> SOz. Draw me a picture?

I am zeroing in on the aura<->ozone bits in this CL. Forget about displays
because that doesn't even show up in the interface.

For ozone, a "window" should just be whatever semantics aura requires. So 1:1
strict owning relationship between [Desktop]WindowTreeHostOzone
(platform-independent) and WindowOzone (platform-dependent).

Similarly, SurfaceOzone is the semantics compositor & gpu need, with strict
owning 1:1 relationship between SoftwareOutputDeviceOzone/GLSurface
(platform-independent) and SurfaceOzone (platform-independent). Surface is for
painting only so narrower in scope than window.

This mostly all just falls out of the modularity requirements placed on ozone by
the design of chrome.