Fix UiThreadGpu initialization for video accelerator tests

Fix UiThreadGpu initialization for video accelerator tests

The UiThreadGpu shouldn't be initialized multiple times for the same
OzonePlatform. This fixes failing DCHECKs in the decode accelerator
unittests.

BUG=447798
Committed: https://crrev.com/09b7de5dd7254947cd4306de907274fa63373d48
Cr-Commit-Position: refs/heads/master@{#317474}

[dnicoara, 2015-02-18 02:27:17]

dnicoara@chromium.org changed reviewers:
+ posciak@chromium.org, spang@chromium.org

[dnicoara, 2015-02-18 02:27:18]

spang@ for Ozone review
posciak@ for owners review

[Pawel Osciak, 2015-02-18 03:17:28]

On 2015/02/18 02:27:18, dnicoara wrote:
> spang@ for Ozone review
> posciak@ for owners review

lgtm

[spang, 2015-02-18 07:33:12]

All of the ozone APIs are used from the rendering thread, so UiThreadGpu should
ideally be initialized on that thread. Looks like creating it in
RenderingHelper::InitializeOneOff() will work.

[dnicoara, 2015-02-18 17:08:44]

On 2015/02/18 07:33:12, spang wrote:
> All of the ozone APIs are used from the rendering thread, so UiThreadGpu
should
> ideally be initialized on that thread. Looks like creating it in
> RenderingHelper::InitializeOneOff() will work.

That's not quite true. RenderingHelper is a mix of functions executed on the
main (UI) thread and calls executed on the rendering thread. I can move it in
RenderingHelper::InitializeOneOff(), but then I'd have to make it static.

[spang, 2015-02-18 19:35:45]

On 2015/02/18 17:08:44, dnicoara wrote:
> On 2015/02/18 07:33:12, spang wrote:
> > All of the ozone APIs are used from the rendering thread, so UiThreadGpu
> should
> > ideally be initialized on that thread. Looks like creating it in
> > RenderingHelper::InitializeOneOff() will work.
> 
> That's not quite true. RenderingHelper is a mix of functions executed on the
> main (UI) thread and calls executed on the rendering thread. I can move it in
> RenderingHelper::InitializeOneOff(), but then I'd have to make it static.

Ahhh ok. In that case, UiThreadGpu cannot be used as-is. It is only usable when
the GPU thread and UI thread are the same, otherwise every single message sent
is delivered on the wrong thread. This is really unsafe.

It is straightforward to generalize to UiThreadGpu to work with two threads, so
that's one possible solution.

[dnicoara, 2015-02-19 01:08:53]

New patchsets have been uploaded after l-g-t-m from posciak@chromium.org

[dnicoara, 2015-02-19 01:11:29]

On 2015/02/18 19:35:45, spang wrote:
> On 2015/02/18 17:08:44, dnicoara wrote:
> > On 2015/02/18 07:33:12, spang wrote:
> > > All of the ozone APIs are used from the rendering thread, so UiThreadGpu
> > should
> > > ideally be initialized on that thread. Looks like creating it in
> > > RenderingHelper::InitializeOneOff() will work.
> > 
> > That's not quite true. RenderingHelper is a mix of functions executed on the
> > main (UI) thread and calls executed on the rendering thread. I can move it
in
> > RenderingHelper::InitializeOneOff(), but then I'd have to make it static.
> 
> Ahhh ok. In that case, UiThreadGpu cannot be used as-is. It is only usable
when
> the GPU thread and UI thread are the same, otherwise every single message sent
> is delivered on the wrong thread. This is really unsafe.
> 
> It is straightforward to generalize to UiThreadGpu to work with two threads,
so
> that's one possible solution.

spang@, please take another look. I made it so posting messages are done
correctly.

[spang, 2015-02-19 01:52:20]

On 2015/02/19 01:11:29, dnicoara wrote:
> On 2015/02/18 19:35:45, spang wrote:
> > On 2015/02/18 17:08:44, dnicoara wrote:
> > > On 2015/02/18 07:33:12, spang wrote:
> > > > All of the ozone APIs are used from the rendering thread, so UiThreadGpu
> > > should
> > > > ideally be initialized on that thread. Looks like creating it in
> > > > RenderingHelper::InitializeOneOff() will work.
> > > 
> > > That's not quite true. RenderingHelper is a mix of functions executed on
the
> > > main (UI) thread and calls executed on the rendering thread. I can move it
> in
> > > RenderingHelper::InitializeOneOff(), but then I'd have to make it static.
> > 
> > Ahhh ok. In that case, UiThreadGpu cannot be used as-is. It is only usable
> when
> > the GPU thread and UI thread are the same, otherwise every single message
sent
> > is delivered on the wrong thread. This is really unsafe.
> > 
> > It is straightforward to generalize to UiThreadGpu to work with two threads,
> so
> > that's one possible solution.
> 
> spang@, please take another look. I made it so posting messages are done
> correctly.

Name & documentation need fixing. Maybe InProcessGpuChannel or TestGpuChannel?
Or more generally, OzoneGpuTestHelper?

[spang, 2015-02-19 01:55:09]

https://codereview.chromium.org/936703002/diff/40001/ui/ozone/public/ui_threa...
File ui/ozone/public/ui_thread_gpu.cc (right):

https://codereview.chromium.org/936703002/diff/40001/ui/ozone/public/ui_threa...
ui/ozone/public/ui_thread_gpu.cc:45: browser_task_runner_->PostTask(
s/browser_/ui_/

Browser is a process, not a thread.

[dnicoara, 2015-02-19 06:04:33]

Renamed it to OzoneGpuTestHelper.

https://codereview.chromium.org/936703002/diff/40001/ui/ozone/public/ui_threa...
File ui/ozone/public/ui_thread_gpu.cc (right):

https://codereview.chromium.org/936703002/diff/40001/ui/ozone/public/ui_threa...
ui/ozone/public/ui_thread_gpu.cc:45: browser_task_runner_->PostTask(
On 2015/02/19 01:55:09, spang wrote:
> s/browser_/ui_/
> 
> Browser is a process, not a thread.

Done.

[spang, 2015-02-19 18:09:41]

lgtm

[dnicoara, 2015-02-21 00:48:21]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2015-02-21 00:49:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/936703002/60001

[commit-bot: I haz the power, 2015-02-21 01:20:09]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-02-21 01:21:07]

Patchset 4 (id:??) landed as
https://crrev.com/09b7de5dd7254947cd4306de907274fa63373d48
Cr-Commit-Position: refs/heads/master@{#317474}