[Enhancement]: Support initializing Wine during snap installation to accelerate first-time launch speed

[brlin-tw]

What changes would you like?

It appears that the gnome extension uses the configure hook(e.g. /snap/notepad-plus-plus/current/snap/command-chain/hooks-configure-desktop) to create the FontConfig cache during snap installation, this cuts down first launch time as it won't need to do it in runtime.

I wonder whether we can use the same mechanism in Wine initialization as well as it also takes a great amount of time(~minutes) during the first launch?

Any extra information?

No response

[merlijn-sebrechts]

Hm, this is an interesting idea.

I have one concern though: wine initialization is quite a complicated process which might contact the internet and show a GUI. This happens, for example, if wine-mono isn't available yet and the dll hack to stop that dialogue isn't present. :thinking:

I don't think Snap hooks support showing GUIs, do they? Feel free to create a PoC of this to see if it works.

[brlin-tw]

I've dived into this issue these days and here what I discover by far:

• Although snap hooks can specify to be connected to certain interfaces during runtime, showing GUI however is not possible at least using the desktop and x11 interfaces due to the fact that snap hooks are run in the system context instead of the calling user's, i.e. it doesn't have access to the user's home directory and process sockets. Wine initialization seems to work without GUI but seems to be only in the bare configuration(i.e. Mono/Gecko installation is disabled, no other winetricks are applied).

  We could probably work around this by making it run in a separate X server(Xvfb), however, Xvfb isn't runnable in the snap runtime and some winetricks probably need user interaction anyway so it is not preferable.

• Due to the reason mentioned above, it also can't access SNAP_USER_COMMON which is the location where Wine initialization data is written and expected to be
• The snap hooks can access the SNAP_COMMON system-wide directory(where gnome-platform generates Fontconfig caches), however, this directory is not writable in the user context (owned by root/root) thus we can't simply point to it there in the Sommelier script.

As it isn't currently possible/feasible to implement, closing.

[merlijn-sebrechts]

Ok, thanks for the deep-dive!

[brlin-tw]

I put my work-in-progress PoC code here, just if anyone likes to take the challenge: https://github.com/brlin-tw/sommelier-hook-speedup-poc