All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=688181

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgyPGesQoM


Bot(s) for this bug's original alert(s):

win

FYI +fjhenigman for the ANGLE roll. I didn't notice an obvious commit in the roll that might cause this (and it's not a huge regression). Feel free to mark as wontfix if you don't think this is worth digging into.

I think it's worth looking into because while it's .4% to chrome, it looks like ANGLE grew by closer to 30%.
http://go/angle-sizes

Seems to be Windows only?  I did some Linux builds and didn't see a jump at any point in the range ccab69d..ea20d62.

I can try to bisect on Windows tomorrow, unless someone happens to know the cause.

For reference, this was the roll: https://chromium.googlesource.com/angle/angle.git/+log/ccab69d..ea20d62

I suspect this is with the inclusion of glslang for Vulkan/ANGLE. Will confirm locally.

Jason, I can confirm this regression was due to the inclusion of Vulkan's glslang in ANGLE. Any advice? We could potentially disable this in stable if it's a big problem.

Thanks Jamie. I'm not familiar with glslang, so I'm probably not the best person to make the revert call. Would you mind sharing a quick tl;dr of what the inclusion will get us? (And is it odd that this appears to only inflace the size on windows?)
If you believe the inclusion is worth the size regression and recommend marking wontfix, at least we'll have the justification recorded for posterity. :)
Thanks for digging into this!

ANGLE is a graphics API translator currently used on Windows to transform OpenGL ES (used internally by Chrome) to Direct3D9 and 11 which are better supported on Windows. We are working on supporting other backend APIs, in particular Vulkan, which uses SPIRV, a different kind of shading language. ANGLE includes the reference compiler, glslang to translate from the OpenGL ES shading language to the Vulkan shading language.

However Vulkan support is in very early stage and isn't needed by Chrome anytime soon. I think we should disable the Vulkan backend unless it is explicitly enabled via some gn args (useful for testing).

The Vulkan back-end isn't accessible to the API currently, but disabling it unilaterally is not an option since we need to test it on the bots.

Corentin's description is correct. Vulkan will in the future give us a safer, faster graphics implementation on supporting platforms, and is being pursued as well by the Skia and compositing teams. It would be nice to have the same flow for stable Chrome as for development, hence my suggestion in comment #6, but we could potentially disable it in stable until we need it. I'd be happiest with a WontFix resolution.

Jason, the reason it only affects Windows is because ANGLE only ships on Windows currently, though we plan to ship on Linux in the near future and other platforms hopefully this year (no current issue open).

Sorry Corentin, yes, we could use gn args, but it would lead to complexities for integration on our end. I'd still like to close as WontFix. Please re-open this if that's not an acceptable justification.

 Issue 710178  has been merged into this issue.