Bake / Optimize / Preload / Prebuild UGUI Canvases using sort order doesn't work, probably should

My objective is to optimize the hiding / showing a keyboard built in unity UI. I observe an issue in Unity WebGL builds on mobile in 2018.3.11 where showing this keyboard built in UGUI has almost a 2 second delay, which is insane, so there's some bug here anyway but what can I do.

Obviously, if WebGL on mobile could just SHOW a keyboard correctly when a user tapped an InputField, I wouldn't be building this Rube Goldberg machine of trying to show a keyboard inside Unity, and everything would be alright. But due to some insane reason, making the native keyboard show on one of the world's largest platforms -- the web, on iOS devices -- is a "wontfix".

Since this uses many sliced button assets (33 game objects) it puts 3140 verts in one batch. My mitigation is:

1. Put the keyboard in its own canvas with a sort order behind the main canvas of the 2D game.
2. Changing the sort order at runtime when it needs to be shown.

To my intense confusion, it would appear that changing the sort order of overlay canvases (1) throws out the rendered batch and (2) the first "preload" render is done with incorrect alpha (!) the first time. Please see the attached images: https://imgur.com/a/8aUfn8u

What is the best way to "preload" or "bake" or pre-build a canvas and its hierarchy in modern Unity? Or why is it unusually and brokenly slow in WebGL?

keywords: preload prebuild load build canvas static batch verts sort order ugui ui bake optimize hierarchy gameobject active alpha interactable

 

EventSystem.Update gets 2100ms in the profiler on WebGL. I can't deep profile. Surely 33 buttons doesn't cause a 2100ms delay.

 

You'd be surprised...

Do you have some ContentSizeFitter, VerticalLayoutGroup, or HorizontalLayoutGroup components in your scene?
If so, try deactivating them (so let them do their layout, and then deactivate)

 

I did deactivate them, as I had a feeling they were trouble, but it didn't appear to improve things. Other mitigations I tried:

(1) Changing the ancient third party code that initializes the keyboard from using "onClick" and delegates to using a separate MonoBehaviour with the appropriate pointer interface on every button.
(2) Delaying a frame from the click. Just changes the accounting: UniRx's internal microcoroutine now has a 2100ms delay.
(3) Replacing all 33 text objects with a single image, pre-baked.
(4) Leaving the keyboard open on startup, where it does not appear to have a problem loading. Only when it reopens is there a huge delay once. The third party code uses Awake to do its initialization, and I've tried the following strategies to diagnose whether the third party initialization code is responsible for this weird delay:

(a) activating/deactivate a game object
(b) the game object starts in the scene activated, but the sort order of its dedicated canvas is behind the main UI canvas, so the init code definitely loads.
(c) using a canvas group and setting the keyboard's alpha to 1/0, interactable to true/false and blocks raycasts to true/false

I'm leaning on, there's a IL2CPP bug with the webgl implementation of the input system.

 

Brace yourselves folks:

https://imgur.com/a/Jtqlrn4

That's right, calling DateTime.Now takes 2275ms on an iPhone X in WebGL!

 

There's still the real issue of, how do I "preload" canvases correctly, that I'd welcome any guidance on. I thought my solution would be pretty good but it looks like reordering canvases throws out cached batches?