Looks like it's loaded from ResourceBundle::LoadChromeResources, but only if IsScaleFactorSupported(SCALE_FACTOR_200P):
https://cs.chromium.org/chromium/src/ui/base/resource/resource_bundle.cc?rcl=0&l=717
I presume this is happening in Chrome? (not mojo:ash or similar, which shouldn't use LOAD_COMMON_RESOURCES).

ResourceBundle::InitSharedInstance always adds SCALE_FACTOR_200P for cros; not sure if that's intentional?
https://cs.chromium.org/chromium/src/ui/base/resource/resource_bundle.cc?rcl=1473160695&l=699

A platform that supports high DPI should have 200 assets as you can connect high DPI displays.

https://cs.chromium.org/chromium/src/ui/base/resource/resource_bundle.cc?rcl=0&l=666

It sounds like the deploy_chrome script isn't copying over chrome_200_resources.pak. That's really odd.

(sdk veyron_minnie R55-8774.0.0) jamescook@rubella2 /w/chrome/src $ deploy_chrome --build-dir=out_veyron_minnie/Release --nostartui --mash --to=172.18.37.37 --target-dir=/home/chrome 
12:27:42: INFO: Staging flags taken from USE in environment: gn
12:27:42: INFO: Testing connection to the device...
12:27:51: INFO: Copying Chrome to /home/chrome on device...
Warning: Permanently added '172.18.37.37' (RSA) to the list of known hosts.
sending incremental file list
./
chrome
chrome-sandbox
chrome-wrapper
chrome_100_percent.pak
***** It should be here, but isn't ******
chrome_manifest.json
chrome_mash_manifest.json

I don't see any recent changes in //third_party/chromite/scripts that would explain a change in behavior.

I changed the deploy code recently, this could be an artifact of that, I will investigate.

I am hitting this problem as well. When you hit this error, are you using the '--target-dir=' flag to deploy_chrome (I am)?

https://chromium-review.googlesource.com/#/c/386417/ might help?

Yeah, I think I was using --target-dir=/home/chrome (you can see /home/chrome in the paths above)

 Issue 649182  has been merged into this issue.

oshima@, continuing discussion from https://chromium-review.googlesource.com/#/c/386417/ :

Simple chrome extracts the USE environment from the chroot that generated the chromeos image being used to build chrome from Chrome OS. 'highdpi' appears to default to true in the ebuild so it should be set there.

I am working on some GN chromite cleanup anyway, so I will look into this today.

highdpi flag is deprected. I thought it's removed. With 4K display, all devices should have high dpi assets.

we have at least one system setting USE=-highdpi (puppy).  that should get cleaned up first.

stevenjb@ -- does b/31636193 look like a dupe of this? Thanks

Seems likely.

Re:#13 so what's the plan, do we want to just remove the cond=C.StagingFlagSet(_HIGHDPI_FLAG)) check in chrome_util.py?

re:#14 I have verified that by removing that condition in chrome_util.py, I can see chrome_200_percent.pak gets included in the "sending incremental file list" when running deploy_chrome from an incremental SimpleChrome build for samus.

So if oshima@'s comment in #10 is correct we should just remove the HIGHDPI flag references in this file.

PTAL https://chromium-review.googlesource.com/#/c/388736/

Sorry, I should have updated this. I have a fix:
https://chromium-review.googlesource.com/#/c/388030/

There was a bug in the deploy_chrome logic from the GN migration. That code is no longer needed so I removed it and verified that the highdpi flag is getting set.

Hopefully the CQ will behave today and this will land (I will chump it if I need to), then we can roll chromite and pick up this + sadrul's change.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/4a6b53c6f2960a61bf8d2686244a0bc6aa1e1737

commit 4a6b53c6f2960a61bf8d2686244a0bc6aa1e1737
Author: Steven Bennetts <stevenjb@chromium.org>
Date: Thu Sep 22 20:13:40 2016

cros_chrome_sdk: Elim no longer needed (and incorrect) USE parsing

BUG= chromium:644408 
TEST=deploy_chrome includes high dpi assets

Change-Id: I5bafa56846008029149c170a8f644617d01bdf83
Reviewed-on: https://chromium-review.googlesource.com/388030
Tested-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/4a6b53c6f2960a61bf8d2686244a0bc6aa1e1737/cli/cros/cros_chrome_sdk.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/f9fd92d7cb31bbdefaf3294523c1a746e3465922

commit f9fd92d7cb31bbdefaf3294523c1a746e3465922
Author: Steven Bennetts <stevenjb@chromium.org>
Date: Tue Sep 27 15:30:38 2016

SimpleChrome: deploy_chrome: Make libwidevine optional

BUG= chromium:644408 ,chromium:612248
TEST=SimpleChromeWorkflow works

Change-Id: Idc2906afb52dfa739788cab9f9d38d5cc14484b5
Reviewed-on: https://chromium-review.googlesource.com/390012
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Luis Hector Chavez <lhchavez@google.com>
Tested-by: Steven Bennetts <stevenjb@chromium.org>

[modify] https://crrev.com/f9fd92d7cb31bbdefaf3294523c1a746e3465922/lib/chrome_util.py

Any idea when chromite will roll? I hit the 200% assets thing again yesterday afternoon.

Working on it now... should have happend yesterday but there were CQ
problems.

ChromeOs 8872.70.0/55.0.2883.87