This is what both SDL and GLFW do, so it makes sense to be consistent.
Without it it's also impossible to handle keyboard shortcuts such as
Ctrl-C when editing text, which is rather silly.
Insufficient testing, sorry. This got broken after MAGNUM_TARGET_GLES3
deprecation in 87c7eea1e2, but the stupid
variable name was there before already, and it just worked for some
reason, but when the condition got flipped, setting *minor* version to 2
didn't do the right thing anymore. And of course, typical Emscripten,
it didn't complain at all in either case.
Took me an embarrassingly long time to spot what was wrong.
Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
I.e., when the page is zoomed. Until now it was only triggered when the
actual canvas was resized, which happens with the zoom only if the
canvas fills the whole window.
This makes them consistent with window and framebuffer size queries,
that are also not cached but queried every time. It fixes a case where a
global UI scaling change in the OS triggered a viewport event but the
event didn't actually have the DPI scaling value updated.
It doesn't however handle actual explicit DPI change events yet, that's
another nightmare altogether.
Same as the corresponding change in Corrade, this allows each function
to explicitly specify its dependencies, making it no longer depending on
what a particular Emscripten version decides to include by default, or
forcing users to painstakingly fill the EXPORTED_FUNCTIONS array when
linking the final executable.
It also allows the code to eventually get conditionally included or not
with preprocessor branches, for example to not include environment
queries for code that won't ever access Node.js console.
It's now possible to choose between low power, high performance and
default, while before it was only possible to switch between low power
and high performance. The old flag is an deprecated alias to the
low-power one.
This makes the minimal supported Emscripten version 1.39.5. With some
more effort this could be changed to 1.38.27, but I don't think anybody
needs that.
AsciiToString is not included by default on 3.1.21+ and including it is
basically impossible on the library side because I don't think they
fixed the case of supplying multiple DEFAULT_LIBRARY_FUNCS_TO_INCLUDE
options on the command line in order to concatenate those lists yet.
Also, given that UTF8ToString is probably already used in other places
since it's included by default, using AsciiToString would only mean
inflating the JS code.
The code right below is querying the `log` option, which wasn't added.
Becomes a problem when Magnum is compiled w/o GL support, e.g. for a
custom WebGPU renderer.
Which allows to get rid of a now-unneeded ArrayView include in the
header. Also, now that we're returning a StringView, it's useful to
have the view always null-terminated. In SDL2 and Emscripten it was
already like that, GLFW needed a minor change.
This removes one unnecessary allocation from each application startup.
In some cases of the windowless apps the Platform::GLContext could be
put directly into the class, in other cases it had to be wrapped in an
Optional because we need delayed construction and/or earlier
destruction.
So in case it touches the GL state in some way, it doesn't do that on an
already destroyed context. The windowless apps do this all implicitly
due to the WindowlessGLContext encapsulation.
Disabling engine startup log or modifying enabled extensions /
workarounds from the application side was one of the common pain
points and this should *finally* solve the problem. This Configuration
is now inherited by the usual Platform::*Application::GLConfiguration /
Platform::Windowless*Application::Configuration classes people are used
to, so for the end user it's just as if these classes got a bunch new
options.
Having this, I also extended the ContextGLTest to verify that the
Configuration and command-line options do what's expected because that
hadn't automated tests until now. The test is mostly a copy of what I
did for Vulkan already, nothing special. Additionally all
Platform*ApplicationTest executables gained a new --quiet option to
verify that the GL::Context::Configuration subset gets correctly passed
from the Application code, because that's something we can't really
verify in an automated way.
It was printing 0 before, which isn't correct. Also why not print both
values? Printing just the first one would hide issues where the second
is accidentally 0 or some other wrong value.
And properly account for -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR.
Module['canvas'] can be read even from code compiled with -s MODULARIZE
so it's a preferrable option to hardcoding it in Configuration. The
target strings in Emscripten depend on whether we're compiled with
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR (see
https://github.com/emscripten-core/emscripten/pull/7977). This is now
detected and handled at runtime to prepend element IDs with and use
the correct window and document magic targets.
Not yet sure about all interactions with older Emscripten versions and
DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR set to 0, reverting until
it's clear.
This reverts commit c760acb548.
Instead of first entering the main loop, processing events etc. This
also makes it finally possible to exit the application cleanly, with all
non-global destructors executed as well.
The canvasX/Y properties were silently deprecated (I wouldn't know
without looking at the source, the docs say no such thing) and when
-s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is enabled, these are
not initialized to any meaningful value.