Add ability to use preloaded resources via rel=preload

[nascent]

Hi,

I am getting used to the new API, and really like it compared to how things worked in the past and I have managed to remove JQuery from my pages, however I have also started working with preloading resources, e.g.,

<$scorefont>;rel=preload;as=font;crossorigin

however it does not work with AlphaTab, since the resource is merely downloaded again, whether via HTML, or JavaScript.

I know there is no "as" attribute, for sf2, but being able to at least use fonts in what is arguably a standard way, I believe would help in relation to faster page loads and interactivity, since Lighthouse shows scores well below 50 and I think this is an area where improvement might be able to be made.

In addition, the library does not seem to work well with the Service Worker specification, and while the specification itself has not been formalized, I believe it to be part of the future of the web; in particular for Progressive Web Applications, and installing single pages to devices.

All in all, this is a great library, the only one worth working with in my view because of the fantastic support provided, which does not result in deadware.

[Danielku15]

Hi there.

I haven't used preloaded resources before and just did a quick reading on them. Here some feedback to get the discussion started:

Bravura Music Font

As you know alphaTab uses the SMuFL compatible font Bravura to display the music note symbols. For the normal music font I would expect it to work fine if setup correctly. According to what I've read is that if you embed a <link rel="preload" href="<path to bravura font files>" as="font" type=".." /> and then "request a load" via CSS using @font-face { src: url('<path to bravura font files>'). <path to bravura font files> needs to be the same to make the preloading work. 🤔

alphaTab requests a web-font load via CSS:

alphaTab/src/Environment.ts

Lines 114 to 122 in 657f884

	@font-face {
	font-family: 'alphaTab';
	src: url('${fontDirectory}Bravura.eot');
	src: url('${fontDirectory}Bravura.eot?#iefix') format('embedded-opentype')
	, url('${fontDirectory}Bravura.woff') format('woff')
	, url('${fontDirectory}Bravura.otf') format('opentype')
	, url('${fontDirectory}Bravura.svg#Bravura') format('svg');
	font-weight: normal;
	font-style: normal;

alphaTab uses the FontLoadingChecker to get notified when the font is actually loaded and available before starting any rendering.

So far I do not see where alphaTab might be blocking the use of preloaded web fonts. Font Load is requested via the usual @font-face, and if a preload link tag exists the browser behavior should kick in. If we can narrow down any concrete issue, I'm happy to adjust alphaTab to make it easier compatible with preloaded resources.

Depending on your project setup you might want to supply an explicit https://www.alphatab.net/docs/reference/settings/core/fontdirectory#description to ensure your link tag and alphaTab use the same paths.

Maybe you can prepare a jsfiddle, codepen or similar showing the issue. Then we have a starting point to check why the preload might not work.

SoundFont

The soundfont is indeed a nasty big file degrading performance of the page init. I am aware that loading can take long, that's why we have all the related events to have a proper UI indication that things are still initializing. You will see similar loading indicators when using the proriertary notation renderers like Ultimate Guitar or Soundslice.

There are various ways to address this topic:

1. Minimize your soundfonts.
   I prepared a guide how you can use the multiple soundfont feature to create "smaller" soundfonts.
   https://www.alphatab.net/docs/guides/multiple-soundfonts
   This requires some advanced logic to detect which soundfonts you will need and load it accordingly. The scoreLoaded event will give you the trigger to analyze the Score Model. From there you can extract which midi patches you will need and can only load the soundfont "slices" you will need. There could be more convinient APIs for that, but at this point nobody requested anything there. e.g. there could be an event with the extracted midi events a song will need.

2. Cache the soundfont for your website.
   If you push your soundfont to a CDN and use browser caching mechanism you can increase the loading time for users significantly. As the soundfont will be already on the users PC (local storage, browser cache etc.) it's just a matter of getting it loaded to memory.

The right as value for the soundfont would be fetch as we're loading an arraybuffer via XHR. It# again mainly a matter of getting the URLs right.

e.g. if you use the default Sonivox Soundfont, you can let it point to the JSDelivr CDN: https://www.jsdelivr.com/package/npm/@coderline/alphatab?path=dist%2Fsoundfont

Otherwise I would recommend extending your app/website with a custom local cache (e.g. via local storage, IndexDB, browser cache API). Download the soundfonts on your own via AJAX, put it to the cache and use loadSountFont with the data from your cache.

In addition, the library does not seem to work well with the Service Worker specification, and while the specification itself has not been formalized

Can you elaborate where alphaTab might be lacking of features to be more compliant with the spec? In general I agree that the standard behavior of alphaTab does not do all these things out of the box. But this is also intended like that. alphaTab rather offers a rich API to allow developers to use it in a flexible way. Things might become different in releases like 1.5+ when we really ship an all-in-one control for easy integration without development skills. Until then, loading any external data efficiently and passing it to alphaTab is the "integrators duty". 😉

More preloading

If you preload the overall alphaTab JavaScript bundle via script (and maybe worker). It could make also this a bit faster .When Workers are spawned they are loading the main alphaTab script file. Depending on the browser behavior with caches and preloading this could also give a boost.