Build font contours concurrently

[rms7326]

Using a MIT licensed thread pool written by Barak Shoshany (BS::thread_pool)

Reading TrueType font files and creating atlas' for use with VulkanSceneGraph is a slow, single threaded process especially when the application allows the user to individually select any TrueType font on their system during execution of the product. Reading and converting TrueType fonts to the more efficient .vsgb form cannot be predicted up-font or batched on startup. This change moves the expensive generation of glyph contours to packaged tasks which are submitted to a solid MIT licensed thread pool (included in the vsgXchange source, src/thread-pool). I tried to minimize the code change as much as possible so that reviewing and accepting the code change is easier.

You can find the original code for the thread pool here. I have not made any changes to the single header packaged up with vsgXchange: BS::thread_pool

[robertosfield]

I haven't done a review yet but just from the explanation a big question jumps out.

Why don't you use vsg::OperationThreads?

The vsg::Options class passed into all loaders has an option for assigning one and is already leveraged by the new gltf and 3DTiles loaders so you could look to it see how it can be used. This mechanism allows individual applications to set up how many threads they want to allocate and control affinity of them if they so wish.

And... it doesn't add any new code to the VSG code bases that we would have to maintain, and put up with extra library size footprint and security exposure of adding duplicative code.

Finally, we have @AnyOldName3's submission, which takes a different, single threaded approach to optimizing front loading.

If we are to go we have to make sure they build upon one another, or just pick the one that provides the most consistent speed up and has the least impact on workload to maintain the new code going forward.

[rms7326]

Robert, I'll take a look a vsg::OperationThreads and replace it if (likely) possible. @AnyOldName3's submission, speeds up the single threaded approach approximately 3 times which is great but still not acceptable for someone selecting fonts from a drop-down. Combining the two approaches will produce very acceptable performance on most machines.

[rms7326]

@robertosfield and @AnyOldName3, I reworked the concurrent contour generation code change to use vsg::OperationThreads, modeling it in a similar way to how you used it in src/gltf/gltf.cpp with one minor exception. Instead of creating unnecessary operations when a thread pool isn't provided, the contour generation task is called directly.