reimplement Image Icon's in v7 & FontBook class

[mggower]

No description provided.

[jameslaneconkling]

In order for this to work w/ the image renderer, you'll need to track which remote assets are currently being loaded, and wait to generate the image until after they're rendered. otherwise image exports will be missing icons/labels. also, need to cancel the load task in the event that the node or renderer is destroyed. in v6 I managed this via a callback util called Async.

It's possible that in v7, pixi can now handle this natively via https://pixijs.com/guides/components/assets. Not sure...

[jameslaneconkling]

Lot going on here, so if any of this sounds wrong to you, tell me, definitely not completely confident in everything below.

One source of bugs early on in the previous version was that promises can't resolve synchronously and also can't be cancelled.

Because they can't resolve synchronously, if you create a cache for something like a BitmapFont or image texture, and a getter function returns a promise that immediately resolves in case of a cache hit, the getter will still resolve in the next tick, not synchronously in the same tick (this is by design in the promise spec, and for the life of me I don't know why). This is usually bad, b/c any logic in the then clause won't run until after the current render completes w/ the call to this.app.render().

Because promises can't be cancelled, there's a potential race condition where if you request a texture be created asynchronously, then tear down the Trellis instance before the texture is created, when the promise resolves and the pixi app has been destroyed, trying to create that texture will both throw an error and leak memory.

A final bug I kept running into: the image renderer needs to first render the scene, and if there are remote assets still being loaded, wait for them to load and be rendered before rendering the image.

It's possible to work around these limitations: for the first, have a synchronous cache check that you always use before loading anything. For the second, always check if the app has been destroyed before doing anything pixi related in a then clause. And for the third, check the loading status on all objects. But ultimately this was pretty brittle, so in the previous version I created the Loader abstraction that's backed by this Async util. (it's kind of like a functional promise: it's a higher order function, not a class, and it's synchronous, and cancellable)

My suggestion here would be:

• create webgl/loader/imageLoader.ts, webgl/loader/fontLoader.ts, replacing webgl/textures/font, webgl/textures/icons (decoupling the loading/cacheing of external assets from the creation of image textures, and from the creation of icon or label objects).
• use the loaders something like here before creating any objects (b/c the loaders are synchronous, the callback is called immediately if there's a cache hit).
• cancel loaders when deleting a node/edge (this will noop if all loaders have already resolved).
• once we implement the image renderer, use the loader singletons so the image renderer can track the number of assets still loading.

[jameslaneconkling]

Also, might make sense to roll up #94 into this PR

[mggower]

added edge labels in this PR

[jameslaneconkling]

Left some more suggestions. Overall general theme is that we should strive to keep the NodeRenderer/EdgeRenderer as simple as possible by pushing logic to the objects and textures. NodeRenderer/EdgeRenderers and the parent renderer are already the location of most of the complexity, so anything like asset loading and texture creation/caching/management that can be pushed to the object/texture classes could be a big win.

I was having a harder time reasoning about the behavior and perf implications of the loaders themselves. The things to confirm is that

• rendering a graph w/ 50k nodes/edges doesn't degrade performance in comparison to what's currently on master
• renderer behavior is the same regardless of whether or not a loader is used to load a remote asset (e.g. font: 'sans-serif' which uses a native font, and font: 'roboto' which requires loading a remote font, should both produce equivalent graphs)
• it's possible to know whether remote assets are currently being loaded (so that the image renderer knows to not capture the image until after assets have loaded), and possible to cancel all requests for assets (so that we don't try to create pixi objects after the renderer has been torn down).