This restriction was added to fix#7373 back then, which was a symbol conflict
between FreeType's bundled copy of gzip/zlib, and distro packages.
But we also unbundled FreeType's zlib in #69395 so this is no longer an issue.
On the other hand recent issues pointed out that using system-provided icu4c
or harfbuzz can cause issues (#91401, #100301). We still allow it for now but
raise a warning.
By making sure that Thread always has a valid caller_id we can remove the
check making the function a straightforward getter instead.
In some quick tests we see a repeatable performance improvement of
somewhere around 0.32 mspf in TPS demo.
Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
In order to make CommandQueueMT more maintainable this PR changes the
previous macro hell with variadic templates instead. This makes the
class far more explicit and will allow us to more easily change the way
the class functions in the future.
Furthermore this refactoring has allowed for some optimizations. In
particular by using std::forward to delay the decision of decaying the
type to as late as possible we are able to move the data from the
callsite into our Command buffer and later move it to the call.
In practice what this means is that compared to the old version instead
of copying values 3 times, we can now get away with 1 copy, and 1 move
for lvalues, and just 2 moves for rvalues. This saves quite a few
operations in a hot codepath.
We also now test to make sure that the amount of copies and moves are
what we expect. This way we can spot performance regressions in this
code easily.
Somewhat unscientifically, running TPS-demo by pressing enter and not
touching the controls average mspf, repeatable across many runs:
before: 6.467
after : 6.202
Somehow it would still build fine, but would crash when compiled with GCC 12.2
on Debian 12.
Also re-add wrongly removed Mutex include from `thread_safe.h`, where it's used
in macros.
Add IWYU pragma comments to prevent it from mistakenly flagging those as unused.
When profiling Dome Keeper, I found that in physics_process a HashMap
gets cleared a lot, which ends up calling the Variant destructor.
Calling Variant::clear() dominates this operation.
By not uselessly setting the Type to NIL on destruction we save about
50% of time. This is likely because if there is a simple type in the
Variant that doesn't need destructing, but now we write when we should
just drop the Variant altogether.
Since the value of Variant::type should be unobservable after
destruction this doesn't change any outward behavior.
- Tweak property hint ranges for some networking settings to ensure
the minimum values don't break the debugger entirely.
- Ensure shader time rollover is set to at least 1, as 0 causes a division by
zero to occur.
All relevant project settings are now covered by a range hint.