Remove dependencies on base from SampleApp

Remove dependencies on base from SampleApp
- Change to use mojo::utility::RunLoop
- Move timer from gles2_client_impl to gles2_impl with added api.

BUG=None
TEST=None
R=darin

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

[DaveMoore, 2014-01-08 18:03:33]

Remove unnecessary change

[darin (slow to review), 2014-01-08 18:10:50]

LGTM, but it would be good to get jamesr@'s feedback on the gles2 API change. He
may have a better idea for how to expose vsync.

[commit-bot: I haz the power, 2014-01-08 18:13:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davemoore@chromium.org/128813002/20001

[jamesr, 2014-01-08 20:32:23]

This really doesn't belong on GLES2.  Is the idea with this patch just to move
the needing-a-timer functionality out of mojo apps and into the shell code?

[DaveMoore, 2014-01-08 20:36:47]

On 2014/01/08 20:32:23, jamesr wrote:
> This really doesn't belong on GLES2.  Is the idea with this patch just to move
> the needing-a-timer functionality out of mojo apps and into the shell code?

Yes. We thought that ultimately we'd have a way for gles2 to call back to the
client to draw (based on vsync) so putting this here for now at least got the
right pieces in place if not the right api. Are we mistaken?

[jamesr, 2014-01-08 20:49:37]

This isn't really the right place - but it's probably fine for now. What would
make more sense on a GLES2 interface would be something like a swap callback,
but right now the GLES2 interface doesn't even have swap (we actually route
swaps through the client-side interface that's shuffled through a pointer stored
in a uint64).  Higher-level scheduling information should come through a
different interface that doesn't exist yet and will need to be more
sophisticated.  A closer fit in the mojom interfaces that exist today would be
the viewport, since vsync is viewport-specific, but that's still not right.

Of course raf != vsync as well.

If this helps with something else you're doing feel free to continue and we can
keep iterating.  I'd use less loaded terms for the interface, though.

[commit-bot: I haz the power, 2014-01-08 23:14:39]

List of reviewers changed. jamesr@chromium.org did a drive-by without LGTM'ing!

[jamesr, 2014-01-08 23:15:52]

Oh sorry, didn't mean to shoot this patch.  lgtm if you wanna land as-is.  I
think if the only goal is to remove this one timer dependency from this one mojo
sample app it might be nicer to just provide another interface that does a
callback-after-delay or callback-at-regular-interval and not try to pretend that
it's related to GL, since this isn't the long-term home of this anyway.

[DaveMoore, 2014-01-08 23:22:31]

On 2014/01/08 23:15:52, jamesr wrote:
> Oh sorry, didn't mean to shoot this patch.  lgtm if you wanna land as-is.  I
> think if the only goal is to remove this one timer dependency from this one
mojo
> sample app it might be nicer to just provide another interface that does a
> callback-after-delay or callback-at-regular-interval and not try to pretend
that
> it's related to GL, since this isn't the long-term home of this anyway.

I'm gone for a few days and would like to land now. Next week I'll look at doing
something else.

[commit-bot: I haz the power, 2014-01-08 23:24:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/davemoore@chromium.org/128813002/20001

[commit-bot: I haz the power, 2014-01-08 23:33:39]

Change committed as 243695

[piman, 2014-01-10 02:39:22]

Just saw this patch... I've been trying to implement the proper gles2 bindings
in mojo (through command buffers instead of the current giant hack), and this
puts one more thing in the way - this doesn't belong in GLES2 at all. No more
please.

[darin (slow to review), 2014-01-10 03:05:19]

This is easily undone. It is easily moved to a different service, for
example, or we could go back to the idea of deriving a timer from
MojoWait{Many}.
On Jan 9, 2014 6:39 PM, <piman@chromium.org> wrote:

> Just saw this patch... I've been trying to implement the proper gles2
> bindings
> in mojo (through command buffers instead of the current giant hack), and
> this
> puts one more thing in the way - this doesn't belong in GLES2 at all. No
> more
> please.
>
> https://codereview.chromium.org/128813002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[davemoore (google), 2014-01-13 16:46:37]

Sorry. I was out for a few days. I'm happy to revert or undo or do anything
that helps you make progress.

Dave


On Thu, Jan 9, 2014 at 7:05 PM, Darin Fisher <darin@chromium.org> wrote:

> This is easily undone. It is easily moved to a different service, for
> example, or we could go back to the idea of deriving a timer from
> MojoWait{Many}.
> On Jan 9, 2014 6:39 PM, <piman@chromium.org> wrote:
>
>> Just saw this patch... I've been trying to implement the proper gles2
>> bindings
>> in mojo (through command buffers instead of the current giant hack), and
>> this
>> puts one more thing in the way - this doesn't belong in GLES2 at all. No
>> more
>> please.
>>
>> https://codereview.chromium.org/128813002/
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.