The previously-specified paths were only correct for a static library
build.
I therefore fenced off that code to be specific to static library
builds.
For shared library builds, I added a generator-expression-based
alternative.
Annoyingly, this won't work with static library builds, so we don't get
the concise, reliable version in all circumstances.
I've avoided modifying any of the paths anything ends up at to avoid
breaking changes.
Resolves https://github.com/assimp/assimp/issues/4269
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.
Kim Kulling
AnyOldName3
tangxin
zhucan
朱灿
Alex
Aaron
PencilAmazing
Martin Weber
Pavel Rojtberg
Gargaj
Jan Krassnigg
sfjohnston