Long UI loading time of macOS app

[testcaoy7]

I just get the Outline client software through Mac App Store and I have find that its UI takes long time to load (at least 3 min).

[trevj]

Sorry you've been having trouble with Outline, @testcaoy7. Can you please tell us what version of macOS you're running and roughly the specifications of your system?

[testcaoy7]

I am running the latest Outline from App Store and my macOS is the latest High Sierra.
My device is a 2017 model of MacBook Pro with Touch Bar.

Please note that I am using Outline from China.

[laosb]

This sounds like should be in outline-client.

[testcaoy7]

Both Outline server manager and client has the same issue.

[jab]

What do you see during the 3 minutes while it’s loading? E.g. Does the app UI appear but with invisible text?

(Reminder: All of Polymer’s paper elements depend on Polymer’s font-roboto element, which tries to download Roboto from fonts.google.com if it’s not locally installed (which is the default case on macOS). And fonts.google.com has been blocked in China. Worse, by default Safari/WKWebView used to paint invisible text while waiting forever for its web font to load, though it recently changed that to 3 seconds. In any case, to work around this you can point the font-roboto dependency in bower.jaon to https://github.com/StartPolymer/empty-elements/blob/master/roboto.html
See also PolymerElements/font-roboto#8)

[jab]

(Sorry, the demons in my phone freaked out while I was editing that comment and closed the issue while I was mid-sentence (they must really hate web fonts). Amended and reopened.)

[fortuna]

I wonder if we can embed the fonts and force Polymer to use the embed ones.

…

On Wed, Apr 11, 2018 at 12:18 PM jab ***@***.***> wrote: (Sorry, the demons in my phone freaked out while I was editing that comment and closed the issue while I was mid-sentence (they must really hate web fonts). Amended and reopened.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG7ncdCN9IiBE0q_MzaJqzh8wv92e7Kks5tnizUgaJpZM4TGEMF> .

[jab]

(just responded to you out-of-band)

[alalamav]

We embed font-roboto through the Polymer bower package. Product Sans, the font used for the title, is proprietary and there is not a package that we can consume. I'll see if it is possible to package it; otherwise, we can add a fallback to an SVG.

[jab]

@alalamav Using Polymer's font-roboto, which is what happens by default when you include the paper elements, rather than using font-roboto-local, is exactly the problem.

Take a look at font-roboto's html include:
https://github.com/PolymerElements/font-roboto/blob/master/roboto.html#L10

That relies on fonts.googleapis.com being accessible just so it can download the stylesheet that tells it which fonts to use.

Compare that to what font-roboto-local does:
https://github.com/PolymerElements/font-roboto-local/blob/master/roboto.html

That includes the <style>...</style> content inline locally, and references the required .ttf files that are included locally too:
https://github.com/PolymerElements/font-roboto-local/tree/master/fonts/roboto

This guarantees that on systems that can't access fonts.googleapis.com, they'll still have all they need locally to properly display font-family: Roboto -styled content, without painting it in invisible ink while the fonts.googleapis.com connection times out.

Looking at the server-manager's bower.json as well as the client's, I don't see any "dependencies" entries like

"font-roboto": "PolymerElements/font-roboto-local",  # <- note the "local"

so it looks like this does not only affect "Product Sans" content, but all (paper styles' default) Roboto content too, hence the issues we're seeing that (IIUC) report that none of the UI shows up for 3 minutes.

[jab]

And just to make it clearer, the other approach I was advocating for above, involving the empty-element version of font-roboto, i.e.

"font-roboto": "StartPolymer/empty-elements#1.1.1"

is to ditch the Roboto nonsense altogether (it's just not worth it), and use the platform-specific system UI font available on each platform. This is the direction that a lot of sites have been going in now that major OSes are shipping their own high-quality, high-DPI system UI fonts, and it's much preferred to use a good thing available locally (even if it varies from user to user) than it is to have everyone get the same font but deal with the performance and connection-timeout risks of loading it remotely, or the app-bloating risks of bundling .ttf files (that may or may not include the scripts for all supported languages (latin, cyrillic, vietnamese, arabic, etc.) which either adds further bloat if included, or makes the bundling of latin-only versions pointless for users of other languages – they get nothing back in return for the extra bloat).
See e.g.

• http://markdotto.com/2018/02/07/github-system-fonts/
• https://furbo.org/2018/03/28/system-fonts-in-css/
  etc.

[trevj]

@testcaoy7 Thanks again for the report. This issue should be fixed in https://github.com/Jigsaw-Code/outline-server/releases/tag/v1.0.7.