The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1eb7caa4fa0a3b0f0cb5ecb106d15b03aeefa202

commit 1eb7caa4fa0a3b0f0cb5ecb106d15b03aeefa202
Author: sky <sky@chromium.org>
Date: Fri Sep 16 00:02:46 2016

Adds bug ids to some NOTIMPLEMENTEDs

For better tracking.

BUG=647433, 647412 , 647416 , 647409 , 647421 , 647417 
TEST=none

Review-Url: https://codereview.chromium.org/2345613003
Cr-Commit-Position: refs/heads/master@{#419044}

[modify] https://crrev.com/1eb7caa4fa0a3b0f0cb5ecb106d15b03aeefa202/ash/mus/new_window_delegate_mus.cc
[modify] https://crrev.com/1eb7caa4fa0a3b0f0cb5ecb106d15b03aeefa202/ash/mus/shell_delegate_mus.cc

GpuSupport has the single function IsPanelFittingDisabled(), which is wired through to (in classic ash with content):

  return content::GpuDataManager::GetInstance()->IsFeatureBlacklisted(
      gpu::GPU_FEATURE_TYPE_PANEL_FITTING);

I believe we need this for simplified display mode. Assuming that is true, we'll likely want mus to tell ash about this during startup.
Kyle, does that make sense? Does mus know this information?

All that GpuSupport::IsPanelFittingDisabled() ends up doing is checking the command line flag switches::kDisablePanelFitting on CrOS.

https://cs.chromium.org/chromium/src/content/browser/gpu/gpu_data_manager_impl_private.cc?sq=package:chromium&dr=CSs&l=340

So we could just not use GpuSupport in Shell::Init() and check the command line flag?

Actually, I'm not 100% sure about switches::kDisablePanelFitting being the only thing that disables/enables panel fitting on Chrome OS. 

We would never use swiftshader on device and I don't see GPU_FEATURE_TYPE_PANEL_FITTING getting added to the blacklist anywhere, so I think this is the case, but would need to look further.

+sadrul
Would you happen to know if we need GpuSupport::IsPanelFittingDisabled(), and if so, who knows the state of it? mus?

The gpu-host would have this information, correct (i.e. mus, or chrome-browser).

> I don't see GPU_FEATURE_TYPE_PANEL_FITTING getting added to the blacklist
> anywhere

I think the blacklist can be loaded from some json file (or auto-generated file)? So we may not want to depend on that assumption.

It looks like this routes through content apis. We should have that in mushrome, but not mash, right? I think this should just work in mushrome, but I'm not sure who knows this information in mash. Any suggestions?

For both mushrome and mustash, this information will need to be available to ui::GpuHost. Some refactor work is needed to move the relevant code out of content/ (issue 683226)

Ok. I'm updating the title slightly. Who should own this?

kylechar@ is a good choice

For mushrome with ash, chrome and mus-ws in the same process this shouldn't require any changes I don't think.

For mustash with simplified display management this is blocked on issue 683226. Once mus-ws has a GpuDataManager instance it would be possible to send something over IPC that specifies if GPU panel fitting is disabled but that presents a new problem.

GpuSupport::IsPanelFittingDisabled() is checked for DisplayConfigurator::Init() which is on the critical path for ash startup. So it will slow down startup times. Basically the same problem as getting the initial list of DisplaySnapshots presents.

How come this isn't needed for mushrome? Mushrome uses DisplayConfigurator too, right?

I was confused about how mushrome would be architected. If GpuDataManager lives in mus-ws portion for mushrome then we would need a similar solution to mustash.

We are getting rid of Panel fitting for ChromeOS, and GPUSupport is only there for panel fitting blacklisting and will be removed as well.