We prefer to prevent using chained assignment (`T a = b = c = T();`) as this
can lead to confusing code and subtle bugs.
According to https://en.wikipedia.org/wiki/Assignment_operator_(C%2B%2B), C++
allows any arbitrary return type, so this is standard compliant.
This could be re-assessed if/when we have an actual need for a behavior more
akin to that of the C++ STL, for now this PR simply changes a handful of
cases which were inconsistent with the rest of the codebase (`void` return
type was already the most common case prior to this commit).
Ensure better compatibility when emcc which may run some tools from
different paths (e.g. closure compiler).
This fixes externs include issues with modern emcc using the closure
compiler.
This actually makes sense(?), when running inside an iframe the active
element might be our canvas, while the iframe itself is not active in
the parent window. Since we consume the event, the iframe does not get
focused in Firefox (but does in Chromium-based browsers), so we must
always call focus to handle such occasions.
Note, the editor build requires the mbedtls module to be manually
enabled, as it is currently needed as a ResourceUID dependency.
This will need to be addressed in a separate PR.
In some conditions the events might be generated even when the `gamepad`
object is not accessible due to Security Context requirements.
This commit adds a check to avoid firing the handler in those cases.
Building `target=release` and `target=release_debug` builds with MinGW-GCC
errors when linking with LTO.
Since it's only needed for `target=debug` builds anyway (bigger objects), which
we don't build with LTO, this works around the issue.
Equivalent `-Wa,-mbig-obj` for GCC/Clang.
This started being needed to compile harfbuzz in `target=debug` with MinGW/GCC,
but there doesn't seem to be any drawback to enabling `/bigobj` (aside from
losing support for pre-VS 2005 linkers, which we don't support).
A window can be closed on the server side while processing results from
_NET_CLIENT_LIST, which causes BadWindow fatal errors by default in
XGetWindowProperty.
The only way to safely catch this case is to set an error handler to
ignore BadWindow errors while these commands are processed.
Some platforms (*cough* web *cough*) have hard limits on the number of
threads that can be spawned.
Currently, ThreadPoolWork (mostly used in rendering/physics servers)
will spawn as many threads as CPUs available causing exception on
machines with high CPU count.
This commit adds a new overridable method to OS that returns the default
thread pool size (still the CPU count by default), and overrides it for
the JavaScript platform so it always allocate only one thread.
We can likely improve the whole ThreadPoolWork in the future to always
allocate X amount of threads, and assign jobs to them on the fly, but
that will require some more architectural changes.
Only Vulkan is fully implemented for now, so OpenGL isn't available
in the project manager yet.
This also makes the rendering driver checks use lowercase names
everywhere for consistency.
