And for Sdl2Application print both the keycode and keysym, as the
current way with a keycode seems different from what both GLFW and HTML5
does. But the SDL2 scancode also doesn't feel right because compared to
GLFW and HTML5 it swaps Y and Z on my keyboard. SIGH.
This all looked obviously correct so I never questioned it, but the spec
itself has the order mixed up for an unexplainable reason so it doesn't
match between MouseEvent and MouseMoveEvent.
In the Emscripten build, accepting events in EmscriptenApplication
prevents them from propagating further to the page, such as F1 that
would open a browser help page. That's not the case with SDL as SDL has
no concept of "accepting an event", so just document that in the test
code.
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.
Without this it would fall back to physical DPI, i.e. taken from the
display dimensions. Which sometimes *is* correct, but often isn't what
the users want -- it's common to have a high DPI screen on a laptop
(such as a full HD on a 15.6") but still only use 100% scaling even
though it's a bit tiny. And often it's completely incorrect, depending
on how accidentally misconfigured the system is, and the users won't
even know because almost nothing uses the physical DPI value by default.
This is just documentation-facing, instead of documenting an overload as
having a default-constructed argument simply show just one constructor
with a default value.
Also simplify the wording. They either create an OpenGL context or not
(or not implicitly).
The Configuration class is defined on the Windowless*Context already,
which means it's available at the point where the constructor is defined
and thus there's no need for such workarounds anymore.
It fails on a linker error otherwise. There's a bit of annoying logic
needed for pre-GLVND systems as there it's not possible to link to GLX
without dragging the whole libGL in as well, causing bad conflicts with
libGLES. Which means I can't test this on the CI yet as there CMake is
forced to version 3.5 and finding GLVND is only in 3.10.
This one was spectacular -- ALL uses of it had also #include <tuple> in
order to std::tie() the result into separate major & minor variables. So
much compile time overhead for so little.
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.
There is one already, and I'm not going to use because it's bloated.
Plus there's EmscriptenApplication that doesn't have to pay for the
extra overhead of wrapping HTML5 APIs in SDL APIs.
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
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.
I was abusing the API and passing a negative pitch there to not have to
invert the image by hand. It stopped working in 2.23 when they hardened
the argument checking and, while working correctly, this feature was
accidental and undocumented.
Unfortunately it broke silently, because the API returned nullptr and
SDL_SetWindowIcon(..., nullptr) is then resetting an icon to nothing. So
I'm adding an internal assertion there now. Hopefully it doesn't start
blowing up for some reason again, heh.
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.
Say how many devices there were in total, so it's possible to
distinguish the case of trying to find a CUDA device on a machine with
no NVidia GPU (where it says it found some other EGL devices) and the
case of drivers being completely broken for some reason (where it says
it didn't find any device at all).
Vladimír Vondruš