Not for review.

Not for review.

End to end prototype of getting a buffer to display via an overlay.

BUG=

[alexst (slow to review), 2014-01-09 21:02:41]

https://codereview.chromium.org/132543002/diff/1/gpu/GLES2/gl2extchromium.h
File gpu/GLES2/gl2extchromium.h (right):

https://codereview.chromium.org/132543002/diff/1/gpu/GLES2/gl2extchromium.h#n...
gpu/GLES2/gl2extchromium.h:630: GL_APICALL void GL_APIENTRY
glSetOverlayPlaneCHROMIUM(GLint plane_id,
This isn't intended to be part of GLES, it's meant to be more like the
SwapBuffers() call and exposed on the context support. Names/plumbing will
probably need to be adjusted.

[alexst (slow to review), 2014-01-09 21:15:55]

https://codereview.chromium.org/132543002/diff/1/cc/output/compositor_frame_m...
File cc/output/compositor_frame_metadata.h (right):

https://codereview.chromium.org/132543002/diff/1/cc/output/compositor_frame_m...
cc/output/compositor_frame_metadata.h:42: gfx::Rect overlay_position;
This is a quick hack to plumb one overlay buffer id.

[rjkroege, 2014-01-10 19:14:04]

I think I see how the code here aligns with the architecture that we put in the
design doc but a paragraph explaining would help me.

https://codereview.chromium.org/132543002/diff/40002/cc/output/overlay_render...
File cc/output/overlay_renderer.cc (right):

https://codereview.chromium.org/132543002/diff/40002/cc/output/overlay_render...
cc/output/overlay_renderer.cc:25: class SingleOverlayOnTop : public
OverlayRenderer::Strategy {
the notion here is that in the fullness of time that there could be a range of
different strategies? The strategy encompasses the "can i overlayz my layerz?"
concept?

https://codereview.chromium.org/132543002/diff/40002/cc/output/overlay_render...
cc/output/overlay_renderer.cc:35: bool
SingleOverlayOnTop::Attempt(RenderPassList* render_passes_in_draw_order) {
An alternate implementation would have this wending its way off the to the HAL
yes?

https://codereview.chromium.org/132543002/diff/40002/cc/output/overlay_render...
File cc/output/overlay_renderer.h (right):

https://codereview.chromium.org/132543002/diff/40002/cc/output/overlay_render...
cc/output/overlay_renderer.h:15: class CC_EXPORT OverlayRenderer {
I think this class probably needs some docs?

https://codereview.chromium.org/132543002/diff/40002/cc/output/software_overl...
File cc/output/software_overlay_presenter_hal.h (right):

https://codereview.chromium.org/132543002/diff/40002/cc/output/software_overl...
cc/output/software_overlay_presenter_hal.h:14: class CC_EXPORT
SoftwareOverlayPresenterHAL {
needs some docs too.

This is the abstraction to the HAL layer?

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/overlay_hal...
File ui/gfx/ozone/overlay_hal_ozone.h (right):

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/overlay_hal...
ui/gfx/ozone/overlay_hal_ozone.h:16: class GFX_EXPORT OverlayHALOzone {
This is the top-level interface to the HAL right?

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/overlay_hal...
ui/gfx/ozone/overlay_hal_ozone.h:48: static OverlayHALOzone* CreateTestHelper();
can these be structured so that they are unavailable to non-test code.
private/friend etc.?

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
File ui/gfx/ozone/surface_factory_ozone.h (right):

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
ui/gfx/ozone/surface_factory_ozone.h:138: virtual void*
GetFunctionPointerFromNativeLibrary(base::NativeLibrary library,
Why? this doesn't seem to belong here.

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
ui/gfx/ozone/surface_factory_ozone.h:141: virtual void SetOverlayPlane(int
plane_id,
what does this do?

https://codereview.chromium.org/132543002/diff/40002/ui/gl/gl_image_egl.cc
File ui/gl/gl_image_egl.cc (right):

https://codereview.chromium.org/132543002/diff/40002/ui/gl/gl_image_egl.cc#ne...
ui/gl/gl_image_egl.cc:33: EGL_NATIVE_PIXMAP_KHR,
won't this change break something?

https://codereview.chromium.org/132543002/diff/40002/ui/gl/gl_image_egl.cc#ne...
ui/gl/gl_image_egl.cc:98: /*DCHECK(egl_image_);
you've had to remove this because the surfaces in the overlay don't necessarily
end up in a texture?

[dnicoara, 2014-01-21 21:22:42]

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/dri/hardwar...
File ui/gfx/ozone/dri/hardware_display_controller.cc (right):

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/dri/hardwar...
ui/gfx/ozone/dri/hardware_display_controller.cc:192: overlay_plane_rect_,
I know this is hacked for now and will receive much love, but I was wondering if
you have an opinion on how we should handle multiple overlays for the same
display?

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
File ui/gfx/ozone/surface_factory_ozone.h (right):

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
ui/gfx/ozone/surface_factory_ozone.h:138: virtual void*
GetFunctionPointerFromNativeLibrary(base::NativeLibrary library,
On 2014/01/10 19:14:04, rjkroege wrote:
> Why? this doesn't seem to belong here.

Ignore this. This is legacy from the hacked GBM backend.

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
ui/gfx/ozone/surface_factory_ozone.h:141: virtual void SetOverlayPlane(int
plane_id,
This may need to have another gfx::AcceleratedWidget parameter to represent the
actual widget/display for the overlay plane.

https://codereview.chromium.org/132543002/diff/40002/ui/gfx/ozone/surface_fac...
ui/gfx/ozone/surface_factory_ozone.h:145: virtual gfx::AcceleratedWidget
CreateNativeBuffer(gfx::Size size,
Would we need to use this for anything other than overlays?