Add very simple cc::Display implementation for surfaces.

Add very simple cc::Display implementation for surfaces.

This just takes the root surface and displays it using a delegated renderer layer.

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

[jamesr, 2014-05-28 22:01:28]

Seems fine to bootstrap the display using a tree/layer, but we should at least
file a bug and add an in-code TODO explaining that it's temporary.

The intended layering is that cc/* can depend on cc/surfaces/ as a lower-level
substrate, but cc/surfaces should only depend on /quads/, /output/, /base/ and
some of /resources/ and eventually move out of cc entirely.

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h
File cc/surfaces/display.h (right):

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
cc/surfaces/display.h:44: virtual void WillBeginMainFrame(int frame_id) OVERRIDE
{}
add some sort of comment indicating that these are LayerTreeHostClient overrides

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
cc/surfaces/display.h:57: virtual void ScheduleComposite() OVERRIDE;
ditto for LTHSTClient

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
cc/surfaces/display.h:62: virtual void UnusedResourcesAreAvailable() OVERRIDE {}
same for DFRCC

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h
File cc/surfaces/surface.h (right):

https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h#ne...
cc/surfaces/surface.h:32: scoped_ptr<CompositorFrame> TakeFrame();
this isn't right - a surface retains ownership of the frame always. to draw a
frame from a surface, you have to clone it or (more likely) aggregate it into a
unified frame that includes data from all referenced surfaces. it's easy enough
to just stack allocate an aggregator and run it to get a frame for one surface
which effectively just copies the data

[jbauman, 2014-05-28 22:03:54]

On 2014/05/28 22:01:28, jamesr wrote:
> Seems fine to bootstrap the display using a tree/layer, but we should at least
> file a bug and add an in-code TODO explaining that it's temporary.
> 
> The intended layering is that cc/* can depend on cc/surfaces/ as a lower-level
> substrate, but cc/surfaces should only depend on /quads/, /output/, /base/ and
> some of /resources/ and eventually move out of cc entirely.
> 
> https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h
> File cc/surfaces/display.h (right):
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:44: virtual void WillBeginMainFrame(int frame_id)
OVERRIDE
> {}
> add some sort of comment indicating that these are LayerTreeHostClient
overrides
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:57: virtual void ScheduleComposite() OVERRIDE;
> ditto for LTHSTClient
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:62: virtual void UnusedResourcesAreAvailable() OVERRIDE
{}
> same for DFRCC
> 
> https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h
> File cc/surfaces/surface.h (right):
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h#ne...
> cc/surfaces/surface.h:32: scoped_ptr<CompositorFrame> TakeFrame();
> this isn't right - a surface retains ownership of the frame always. to draw a
> frame from a surface, you have to clone it or (more likely) aggregate it into
a
> unified frame that includes data from all referenced surfaces. it's easy
enough
> to just stack allocate an aggregator and run it to get a frame for one surface
> which effectively just copies the data

Yeah, this was a hack to make it display something. The aggregator doesn't work
yet because it doesn't aggregate the resource list, so I just threw this
together until I got that working.

[jbauman, 2014-05-28 23:07:21]

PTAL. Added some comments and switched it to copy the DelegatedFrameData.

On 2014/05/28 22:01:28, jamesr wrote:
> Seems fine to bootstrap the display using a tree/layer, but we should at least
> file a bug and add an in-code TODO explaining that it's temporary.
> 
> The intended layering is that cc/* can depend on cc/surfaces/ as a lower-level
> substrate, but cc/surfaces should only depend on /quads/, /output/, /base/ and
> some of /resources/ and eventually move out of cc entirely.
> 
> https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h
> File cc/surfaces/display.h (right):
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:44: virtual void WillBeginMainFrame(int frame_id)
OVERRIDE
> {}
> add some sort of comment indicating that these are LayerTreeHostClient
overrides
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:57: virtual void ScheduleComposite() OVERRIDE;
> ditto for LTHSTClient
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/display.h#ne...
> cc/surfaces/display.h:62: virtual void UnusedResourcesAreAvailable() OVERRIDE
{}
> same for DFRCC
> 
> https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h
> File cc/surfaces/surface.h (right):
> 
>
https://codereview.chromium.org/302903003/diff/20001/cc/surfaces/surface.h#ne...
> cc/surfaces/surface.h:32: scoped_ptr<CompositorFrame> TakeFrame();
> this isn't right - a surface retains ownership of the frame always. to draw a
> frame from a surface, you have to clone it or (more likely) aggregate it into
a
> unified frame that includes data from all referenced surfaces. it's easy
enough
> to just stack allocate an aggregator and run it to get a frame for one surface
> which effectively just copies the data

[jamesr, 2014-05-28 23:15:47]

lgtm, cool! i think i'll try to page the resources stuff back in next so i can
teach the aggregator how to deal with them so feel free to give that TODO to me
if you'd like

https://codereview.chromium.org/302903003/diff/30001/cc/surfaces/display.cc
File cc/surfaces/display.cc (right):

https://codereview.chromium.org/302903003/diff/30001/cc/surfaces/display.cc#n...
cc/surfaces/display.cc:92: layer_tree_host_->Composite(base::TimeTicks::Now());
should this be a gfx::FrameTime::Now() instead?

https://codereview.chromium.org/302903003/diff/30001/cc/surfaces/display.h
File cc/surfaces/display.h (right):

https://codereview.chromium.org/302903003/diff/30001/cc/surfaces/display.h#ne...
cc/surfaces/display.h:39: void Resize(const gfx::Size& new_size);
guessing we'll want a scale factor too here someday, but can do that when it
comes time

[jbauman, 2014-05-29 15:37:15]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-05-29 15:39:03]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jbauman@chromium.org/302903003/50001

[jbauman, 2014-05-29 17:36:30]

The CQ bit was unchecked by jbauman@chromium.org

[jbauman, 2014-05-29 17:42:27]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-05-29 17:44:22]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jbauman@chromium.org/302903003/70001

[commit-bot: I haz the power, 2014-05-29 21:33:17]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-05-30 05:23:07]

Change committed as 273719