Add helpers for creating UI components.

mojo/ui/ganesh_renderer.cc

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "mojo/ui/ganesh_renderer.h"
+
+#include "base/bind.h"
+#include "base/logging.h"
+#include "mojo/gpu/gl_texture.h"
+#include "mojo/skia/ganesh_context.h"
+#include "mojo/skia/ganesh_texture_surface.h"
+#include "third_party/skia/include/core/SkCanvas.h"
+#include "third_party/skia/include/core/SkSurface.h"
+
+namespace mojo {
+namespace ui {
+
+GaneshRenderer::GaneshRenderer(mojo::skia::GaneshContext* ganesh_context)
+    : ganesh_context_(ganesh_context),
+      gl_renderer_(ganesh_context_->gl_context()) {
+  DCHECK(ganesh_context_);
+}
+
+GaneshRenderer::~GaneshRenderer() {}
+
+mojo::gfx::composition::ResourcePtr GaneshRenderer::DrawSurface(
+    const mojo::Size& size,
+    const DrawSurfaceCallback& callback) {

[viettrungluu, 2016/01/05 21:53:26]

It may just be me (and my naivete), but I'm a bit ambivalent about this API, in
particular having a callback that you always call inline.

E.g., in reading ShapesView::UpdateScene(), I got to the call to DrawSurface()
and then wondered when the callback (ShapesView::DrawContent()) would be run and
whether I should worry about object lifetime, etc.

I got the feeling that just having this code directly inline in
ShapesView::UpdateScene() would have been a little (but not a lot! -- since
using this helper class then required a separate method, etc.) more verbose, but
more obvious. It makes me wonder a bit about the value of this class.

[abarth, 2016/01/10 23:23:39]

Yeah, I'd skip this function.  It's just making the callers more mysterious
without really adding any value.

[jeffbrown, 2016/01/26 07:25:15]

There are some subtle things going on here such as the fact that the texture is
allocated before entering the Ganesh scope.  (And I just noticed that the call
to BindTextureResource should have happened outside of that scope.)

In practice, writing the drawing code inline obfuscates the little texture
ownership dance so you'll usually want to factor that out to another function
anyhow.  I agree it looks ugly with base::Bind but perhaps not so bad with a
lambda.

Anyhow, I'd like to work on a few more examples before deciding to ditch the
class entirely.  As it is, this pattern has proven to be quite useful so I'm
going to leave it in place for now.

I might still decide I hate it later.

(Historical note: Originally this was part of GaneshView with a simple OnDraw
method to override but coupling rendering to the View proved too restrictive so
I ended up with the callback approach instead to enable broader reuse.)

[viettrungluu, 2016/01/26 18:38:40]

To me the disadvantages are that it's not obvious (upon reading) when the
callback gets called, and that you may have to capture various local variables
(unless you use C++'s "capture everything that's used", which we don't like,
probably for good reason).
I wonder if a scoper type thing wouldn't be better.

+  std::unique_ptr<mojo::GLTexture> texture = gl_renderer_.GetTexture(size);
+  DCHECK(texture);
+
+  mojo::skia::GaneshContext::Scope scope(ganesh_context_);
+  mojo::skia::GaneshTextureSurface texture_surface(scope, std::move(texture));
+
+  callback.Run(texture_surface.surface());
+
+  return gl_renderer_.BindTextureResource(texture_surface.TakeTexture());
+}
+
+static void RunCanvasCallback(
+    const mojo::ui::GaneshRenderer::DrawCanvasCallback& callback,
+    SkSurface* surface) {
+  callback.Run(surface->getCanvas());
+}
+
+mojo::gfx::composition::ResourcePtr GaneshRenderer::DrawCanvas(
+    const mojo::Size& size,
+    const DrawCanvasCallback& callback) {
+  return DrawSurface(size, base::Bind(&RunCanvasCallback, callback));
+}
+
+}  // namespace ui
+}  // namespace mojo