cc: Remove the unused compositor thread variable and interface.

cc: Remove the unused compositor thread variable and interface.

Removes GetCompositorMessageLoop from the ContextFactory interface,
and drops the compositor_thread_ members from the ContextFactory
implementations.

There is no compositor thread in the ui compositor so these are now
excess complication.

R=sievers
BUG=329552
Committed: https://crrev.com/0e5a4b447e3d0af26df0eb5684efaac7f09b4169
Cr-Commit-Position: refs/heads/master@{#317622}

[no sievers, 2015-02-20 02:14:32]

lgtm with a question about sw fallback behavior on CrOS.

https://codereview.chromium.org/943763004/diff/20001/content/browser/composit...
File content/browser/compositor/gpu_process_transport_factory.cc (right):

https://codereview.chromium.org/943763004/diff/20001/content/browser/composit...
content/browser/compositor/gpu_process_transport_factory.cc:240: NOTREACHED() <<
"Shouldn't use software compositing on ChromeOS.";
So with threaded compositing we would get crash reports previously on CrOS for
reaching this. After switching to single-threaded compositing, we then allowed
this to fall back to software here even on CrOS?
I guess we now still do allow fallback to sw in release builds, but not debug
builds. Although we wouldn't run the unittests anymore with this patch, so
things might break. Should we always totally explode here then maybe?

And do you want to DCHECK(!create_software_renderer) for CrOS above?

[danakj, 2015-02-20 03:32:08]

https://codereview.chromium.org/943763004/diff/20001/content/browser/composit...
File content/browser/compositor/gpu_process_transport_factory.cc (right):

https://codereview.chromium.org/943763004/diff/20001/content/browser/composit...
content/browser/compositor/gpu_process_transport_factory.cc:240: NOTREACHED() <<
"Shouldn't use software compositing on ChromeOS.";
On 2015/02/20 02:14:31, sievers wrote:
> So with threaded compositing we would get crash reports previously on CrOS for
> reaching this. After switching to single-threaded compositing, we then allowed
> this to fall back to software here even on CrOS?

ya we did because of those tests which I just fixed in this CL to not software
composite on CrOS.

> I guess we now still do allow fallback to sw in release builds, but not debug
> builds. Although we wouldn't run the unittests anymore with this patch, so
> things might break. Should we always totally explode here then maybe?

Ya good idea, I'll LOG(FATAL) back again.

> And do you want to DCHECK(!create_software_renderer) for CrOS above?

It seems a little bit overkill maybe? I could if you feel strongly.

[danakj, 2015-02-20 03:32:46]

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

[danakj, 2015-02-20 03:32:53]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-02-20 03:33:21]

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

[commit-bot: I haz the power, 2015-02-20 04:25:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-02-20 04:25:34]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[danakj, 2015-02-20 17:23:30]

Found some more tests trying to use software comp on chromeos, disabled them or
removed the software comp when it wasn't related.

[danakj, 2015-02-23 18:47:20]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-02-23 18:47:40]

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

[commit-bot: I haz the power, 2015-02-23 19:39:29]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-02-23 19:40:08]

Patchset 5 (id:??) landed as
https://crrev.com/0e5a4b447e3d0af26df0eb5684efaac7f09b4169
Cr-Commit-Position: refs/heads/master@{#317622}