Add buffer_to_texture_target_map to LayerTreeSettings

Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2857363004
Cr-Commit-Position: refs/heads/master@{#474999}
Committed: https://chromium.googlesource.com/chromium/src/+/88677427eb90210e1f60202602a3dc1eace69da5

[Alex Z., 2017-05-04 20:25:00]

Description was changed from

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
==========

to

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Alex Z., 2017-05-04 20:25:07]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 20:25:47]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alex Z., 2017-05-04 20:27:02]

staraz@chromium.org changed reviewers:
+ danakj@chromium.org

[Alex Z., 2017-05-04 20:27:02]

danakj@: PTAL. You also own cc, gpu_process_transport_factory* 
and ui/compositor. Thanks!

[commit-bot: I haz the power, 2017-05-04 20:29:53]

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

[commit-bot: I haz the power, 2017-05-04 20:29:54]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[Alex Z., 2017-05-04 20:52:52]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 20:53:41]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-04 21:08:31]

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

[commit-bot: I haz the power, 2017-05-04 21:08:32]

Dry run: Try jobs failed on following builders:
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Alex Z., 2017-05-04 21:17:23]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 21:18:47]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-04 21:37:41]

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

[commit-bot: I haz the power, 2017-05-04 21:37:42]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[Alex Z., 2017-05-04 21:53:56]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 21:54:21]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-04 22:19:00]

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

[commit-bot: I haz the power, 2017-05-04 22:19:01]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Alex Z., 2017-05-04 23:35:01]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-04 23:35:36]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-05 00:00:47]

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

[commit-bot: I haz the power, 2017-05-05 00:00:48]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[Alex Z., 2017-05-05 12:41:22]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-05 12:41:38]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-05 13:42:29]

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

[commit-bot: I haz the power, 2017-05-05 13:42:30]

Dry run: This issue passed the CQ dry run.

[danakj, 2017-05-05 17:55:24]

Did you wanna do the ResourceSettings thing first then, or should I review this
as is?

[Alex Z., 2017-05-05 18:11:10]

On 2017/05/05 17:55:24, danakj wrote:
> Did you wanna do the ResourceSettings thing first then, or should I review
this
> as is?

I'll do the ResourceSettings first. Thanks!

[Alex Z., 2017-05-08 19:21:00]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[Alex Z., 2017-05-08 19:21:57]

On 2017/05/05 17:55:24, danakj wrote:
> Did you wanna do the ResourceSettings thing first then, or should I review
this
> as is?

I changed my mind: it will probably require less work if we land this first and
then I work on ResourceSettings than the other way around. 

PTAL.

[commit-bot: I haz the power, 2017-05-08 19:22:20]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-08 19:28:28]

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

[commit-bot: I haz the power, 2017-05-08 19:28:29]

Dry run: Try jobs failed on following builders:
  linux_trusty_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/b...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Alex Z., 2017-05-08 20:06:58]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-08 20:08:07]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alex Z., 2017-05-08 20:14:58]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[Alex Z., 2017-05-08 20:15:12]

Patchset #7 (id:120001) has been deleted

[Alex Z., 2017-05-08 20:15:24]

Patchset #7 (id:140001) has been deleted

[commit-bot: I haz the power, 2017-05-08 20:15:56]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-09 01:20:51]

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

[commit-bot: I haz the power, 2017-05-09 01:20:53]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[danakj, 2017-05-09 22:41:32]

> Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

This is going to sound a bit weird but bear with me. I think it would make more
sense if this was in RendererSettings too. We are already passing a settings
struct to Display, which contains this, and unpacking it from there doesn't seem
needed.

What we need is for consumers of LayerTreeSettings to stop using the
RendererSettings one, and we can do that by putting it on LayerTreeSettings
also, and using that one there.

Here's 2 ways I can think of to approach this quickly:
1. Leave the RendererSettings one empty for the RendererSettings that is inside
LayerTreeSettings.
2. Separate stuff immediately by renaming the RendererSettings inside
LayerTreeSettings to some other type (keeping the RendererSettings for use
everywhere else). The nested used-to-be-RendererSettings could then drop the
buffer_to_texture_target_map freely without impacting Display code, but keeping
it as a member makes for a smaller CL as code accessing
layer_tree_settings.renderer_settings wouldn't all have to change at once.

wdyt?

[Alex Z., 2017-05-10 15:01:59]

On 2017/05/09 22:41:32, danakj wrote:
> > Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings
> 
> This is going to sound a bit weird but bear with me. I think it would make
more
> sense if this was in RendererSettings too. We are already passing a settings
> struct to Display, which contains this, and unpacking it from there doesn't
seem
> needed.
> 
> What we need is for consumers of LayerTreeSettings to stop using the
> RendererSettings one, and we can do that by putting it on LayerTreeSettings
> also, and using that one there.
> 
> Here's 2 ways I can think of to approach this quickly:
> 1. Leave the RendererSettings one empty for the RendererSettings that is
inside
> LayerTreeSettings.
> 2. Separate stuff immediately by renaming the RendererSettings inside
> LayerTreeSettings to some other type (keeping the RendererSettings for use
> everywhere else). The nested used-to-be-RendererSettings could then drop the
> buffer_to_texture_target_map freely without impacting Display code, but
keeping
> it as a member makes for a smaller CL as code accessing
> layer_tree_settings.renderer_settings wouldn't all have to change at once.
> 
> wdyt?

Thanks for the suggestions, Dana!

I'm going to go with option 1 for now because I think it will reduce the size of

this CL without revamping it. Then I will change the RendererSettings inside 
LayerTreeSettings to a ResourceSettings and add a ResourceSettings to 
RedererSettings in a separate CL.

[Alex Z., 2017-05-24 20:49:44]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-24 20:50:28]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-24 21:02:51]

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

[commit-bot: I haz the power, 2017-05-24 21:02:52]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Alex Z., 2017-05-25 14:07:36]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 14:07:54]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alex Z., 2017-05-25 15:12:14]

danakj@: I'm resurrecting this CL since RendererSettings are
initialized in a centralized place now. Bots seem to be happy 
(two are still running as of the time this is posted). PTAL!

[commit-bot: I haz the power, 2017-05-25 15:25:16]

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

[commit-bot: I haz the power, 2017-05-25 15:25:17]

Dry run: This issue passed the CQ dry run.

[danakj, 2017-05-25 15:27:18]

https://codereview.chromium.org/2857363004/diff/200001/cc/test/layer_tree_tes...
File cc/test/layer_tree_test.cc (right):

https://codereview.chromium.org/2857363004/diff/200001/cc/test/layer_tree_tes...
cc/test/layer_tree_test.cc:881: InitializeRendererSettings(&renderer_settings);
It feels a bit too easy for a patch author to forget to call this when
overriding CreateCompositorFrameSink.

What if we pass RendererSettings to CreateCompositorFrameSink instead? Then a
new test overriding it would see the settings there and it would be much harder
to not use them and get the things set by this method?

It would mean moving this call up to RequestNewCompositorFrameSink instead.

https://codereview.chromium.org/2857363004/diff/200001/content/renderer/gpu/r...
File content/renderer/gpu/render_widget_compositor.cc (left):

https://codereview.chromium.org/2857363004/diff/200001/content/renderer/gpu/r...
content/renderer/gpu/render_widget_compositor.cc:390:
cmd.HasSwitch(switches::kEnableColorCorrectRendering);
Where does this get initialized?

[Alex Z., 2017-05-25 17:37:18]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 17:37:47]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alex Z., 2017-05-25 17:39:15]

https://codereview.chromium.org/2857363004/diff/200001/cc/test/layer_tree_tes...
File cc/test/layer_tree_test.cc (right):

https://codereview.chromium.org/2857363004/diff/200001/cc/test/layer_tree_tes...
cc/test/layer_tree_test.cc:881: InitializeRendererSettings(&renderer_settings);
On 2017/05/25 15:27:18, danakj wrote:
> It feels a bit too easy for a patch author to forget to call this when
> overriding CreateCompositorFrameSink.
> 
> What if we pass RendererSettings to CreateCompositorFrameSink instead? Then a
> new test overriding it would see the settings there and it would be much
harder
> to not use them and get the things set by this method?
> 
> It would mean moving this call up to RequestNewCompositorFrameSink instead.

Done.

https://codereview.chromium.org/2857363004/diff/200001/content/renderer/gpu/r...
File content/renderer/gpu/render_widget_compositor.cc (left):

https://codereview.chromium.org/2857363004/diff/200001/content/renderer/gpu/r...
content/renderer/gpu/render_widget_compositor.cc:390:
cmd.HasSwitch(switches::kEnableColorCorrectRendering);
On 2017/05/25 15:27:18, danakj wrote:
> Where does this get initialized?

I must have deleted this by mistake. Thanks for pointing it out!

[danakj, 2017-05-25 17:42:19]

LGTM

https://codereview.chromium.org/2857363004/diff/220001/cc/test/layer_tree_pix...
File cc/test/layer_tree_pixel_test.cc (right):

https://codereview.chromium.org/2857363004/diff/220001/cc/test/layer_tree_pix...
cc/test/layer_tree_pixel_test.cc:59: shared_bitmap_manager(),
gpu_memory_buffer_manager(), RendererSettings(),
I forget, do tests fail if u use |renderer_settings| here?

[commit-bot: I haz the power, 2017-05-25 18:06:13]

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

[commit-bot: I haz the power, 2017-05-25 18:06:14]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[Alex Z., 2017-05-25 18:25:47]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 18:26:38]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alex Z., 2017-05-25 18:27:56]

https://codereview.chromium.org/2857363004/diff/220001/cc/test/layer_tree_pix...
File cc/test/layer_tree_pixel_test.cc (right):

https://codereview.chromium.org/2857363004/diff/220001/cc/test/layer_tree_pix...
cc/test/layer_tree_pixel_test.cc:59: shared_bitmap_manager(),
gpu_memory_buffer_manager(), RendererSettings(),
On 2017/05/25 17:42:19, danakj wrote:
> I forget, do tests fail if u use |renderer_settings| here?

Yes, they fail. We decided to reestablish baseline on a separate CL.
See https://bugs.chromium.org/p/chromium/issues/detail?id=717514

[danakj, 2017-05-25 18:29:04]

Ok thanks :)

On Thu, May 25, 2017 at 2:27 PM, <staraz@chromium.org> wrote:

>
> https://codereview.chromium.org/2857363004/diff/220001/cc/
> test/layer_tree_pixel_test.cc
> File cc/test/layer_tree_pixel_test.cc (right):
>
> https://codereview.chromium.org/2857363004/diff/220001/cc/
> test/layer_tree_pixel_test.cc#newcode59
> cc/test/layer_tree_pixel_test.cc:59: shared_bitmap_manager(),
> gpu_memory_buffer_manager(), RendererSettings(),
> On 2017/05/25 17:42:19, danakj wrote:
> > I forget, do tests fail if u use |renderer_settings| here?
>
> Yes, they fail. We decided to reestablish baseline on a separate CL.
> See https://bugs.chromium.org/p/chromium/issues/detail?id=717514
>
> https://codereview.chromium.org/2857363004/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alex Z., 2017-05-25 18:34:22]

staraz@chromium.org changed reviewers:
+ boliu@chromium.org, piman@chromium.org, sadrul@chromium.org

[Alex Z., 2017-05-25 18:34:24]

boliu@chromium.org: Please review changes in 
compositor_impl_android.cc.

sadrul@chromium.org: Please review changes in 
mus_context_factory.h

piman@chromium.org: Please review changes in 
render_widget_compositor.cc

[piman, 2017-05-25 18:39:40]

lgtm

[commit-bot: I haz the power, 2017-05-25 19:29:04]

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

[commit-bot: I haz the power, 2017-05-25 19:29:05]

Dry run: This issue passed the CQ dry run.

[Alex Z., 2017-05-25 19:32:15]

Description was changed from

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Alex Z., 2017-05-25 19:32:15]

staraz@chromium.org changed reviewers:
- sadrul@chromium.org

[Alex Z., 2017-05-25 19:33:25]

The CQ bit was checked by staraz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 19:33:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-25 21:03:08]

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

[commit-bot: I haz the power, 2017-05-25 21:03:09]

Dry run: This issue passed the CQ dry run.

[boliu, 2017-05-25 23:44:44]

https://codereview.chromium.org/2857363004/diff/260001/content/browser/render...
File content/browser/renderer_host/compositor_impl_android.cc (right):

https://codereview.chromium.org/2857363004/diff/260001/content/browser/render...
content/browser/renderer_host/compositor_impl_android.cc:772:
cc::RendererSettings renderer_settings;
it's not clear to me why this change is relevant to the CL description. And why
should LTH have a different renderer setting from the display now?

[Alex Z., 2017-05-26 12:10:02]

Description was changed from

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

Consumers of LayerTreeSettings should stop using the RendererSettings
inside LayerTreeSettings. The renderer_settings field remains inside
LayerTreeSettings to keep the size of the CL reasonable.

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Alex Z., 2017-05-26 12:13:23]

Description was changed from

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

Consumers of LayerTreeSettings should stop using the RendererSettings
inside LayerTreeSettings. The renderer_settings field remains inside
LayerTreeSettings to keep the size of the CL reasonable.

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Alex Z., 2017-05-26 12:48:40]

Patchset #13 (id:280001) has been deleted

[Alex Z., 2017-05-26 12:48:50]

The CQ bit was checked by staraz@chromium.org

[Alex Z., 2017-05-26 12:48:51]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
piman@chromium.org
Link to the patchset: https://codereview.chromium.org/2857363004/#ps300001
(title: "Address comments in CompositorImpl")

[Alex Z., 2017-05-26 12:48:58]

https://codereview.chromium.org/2857363004/diff/260001/content/browser/render...
File content/browser/renderer_host/compositor_impl_android.cc (right):

https://codereview.chromium.org/2857363004/diff/260001/content/browser/render...
content/browser/renderer_host/compositor_impl_android.cc:772:
cc::RendererSettings renderer_settings;
On 2017/05/25 23:44:44, boliu wrote:
> it's not clear to me why this change is relevant to the CL description. And
why
> should LTH have a different renderer setting from the display now?

You are right. I have reverted this changes.
This CL is part of the effort of separating RendererSettings from
LayerTreeSettings. The whole task is diced up into smaller chunks to
avoid large CLs. Sometimes the border of each CL gets blurred.

As for Display having a different renderer settings, LTH doesn't
consume the renderer settings. It passes it along when creating
Displays and ResourceProviders. We decided to leave some fields as
default instead of deleting them for now to have smaller CLs.

[commit-bot: I haz the power, 2017-05-26 12:49:00]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 13:53:07]

CQ is committing da patch.

Bot data: {"patchset_id": 300001, "attempt_start_ts": 1495802930748340,
"parent_rev": "5eeb08e6e66904d0ee2c96887f98caf8168f73d6", "commit_rev":
"88677427eb90210e1f60202602a3dc1eace69da5"}

[commit-bot: I haz the power, 2017-05-26 13:53:20]

Description was changed from

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Move RendererSettings:buffer_to_texture_target_map to LayerTreeSettings

ContextFactory populates and stores the buffer to OpenGL texture target map.
ui::Compositor copies it into
LayerTreeSettings before using it to create a LayerTreeHost.

The map is used by both LayerTreeHost and cc::Display to create
ResourceProviders but it doesn't go into DirectRenderer or its subclasses.
Letting ContextFactory populate the map centralize the logic compared to the
current state (ui::Compositor populates the map by calling
ContextFactory::GetImageTextureTarget).

BUG=711146
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2857363004
Cr-Commit-Position: refs/heads/master@{#474999}
Committed:
https://chromium.googlesource.com/chromium/src/+/88677427eb90210e1f60202602a3...
==========

[commit-bot: I haz the power, 2017-05-26 13:53:22]

Committed patchset #13 (id:300001) as
https://chromium.googlesource.com/chromium/src/+/88677427eb90210e1f60202602a3...