clickable r598874 -> https://chromium-review.googlesource.com/c/chromium/src/+/1276550

(maybe nico has a sense of build flags that might be missing).

(and +ccameron may have some mac-specific gpu guidance/context).

Hi all. Originally, the libraries themselves were around 2.3 Mb (same as other platforms), but it was requested that the library's symbols from SwiftShader on MacOS get uploaded to our Crash server, which I did. Does this affect the size of the shipped binary?

ccameron@, rsesek@, can you help? I have no idea how to check specifically what gets shipped on MacOS and this is probably trivial for you guys.

The libraries are only about 2.4MB:

% ls -lh /Applications/Google\ Chrome\ Canary.app/Contents/Versions/72.0.3588.0/Google\ Chrome\ Framework.framework/Libraries/
total 11512
drwxrwxr-x  4 rsesek  admin   136B Oct 22 02:50 MEIPreload
drwxrwxr-x  4 rsesek  admin   136B Oct 22 02:50 WidevineCdm
-rwxrwxr-x  1 rsesek  admin    20K Oct 21 23:33 libEGL.dylib
-rwxrwxr-x  1 rsesek  admin   3.2M Oct 21 23:33 libGLESv2.dylib
-rwxrwxr-x  1 rsesek  admin    73K Oct 21 23:42 libswiftshader_libEGL.dylib
-rwxrwxr-x  1 rsesek  admin   2.3M Oct 21 23:43 libswiftshader_libGLESv2.dylib

So I'm not sure how that's getting to 10MB. Would probably need to do a build with and without the suspect change, then compare the results.

> but it was requested that the library's symbols from SwiftShader on MacOS get uploaded to our Crash server, which I did. Does this affect the size of the shipped binary?

No, it doesn't. But because these are being shipped as dylbs they do have symbols rather than being fully stripped like Chrome Framework.

Sorry - my chart reading skills failed. 10MB includes the delta from  Issue 891992  and some extra laziness on my part.

This one is

197046000 -> 202936000

so closer to 5.9MiB / 5.6MB. Still bad. This seems to agree with sum{*.dylib} in #c5.

The commits at, e.g., https://crbug.com/757974#c24 have notes like "This increases the official build size by about 44KB", so it seems this is being tracked.

If it's an intentional/approved regression that's probably OK. But perhaps still worth looking into.

For example, can these dylibs be built with fewer exported symbols?

Or is there a specific symbol that Chrome dlopen()s? Maybe that can be listed in a file passed to `strip -s <dlopen-syms> libGLESv2.dylib` to cut out code in the dylib that will never execute. (disclaimer: I've never done this and don't know if it will achieve anything here :).

Or can we statically link these into Chrome, and what's the diff/payoff of doing that?

Note the linker flags being used for these swiftshader libs is being raised on the other recent sizes regression -  Issue 891992  - for some warnings that are triggered whilst trying to resolve the regression there.