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.
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.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
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.
With this flag set (which is done implicitly for all windowless apps
and, conversely, not done for all windowed apps), the default
framebuffer state isn't touched in any way, which should avoid potential
race conditions with default framebuffer on another thread.
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.
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.
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.
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.
Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
On Emscripten as well, however I'm keeping the Configuration::setTitle()
a no-op because the title is usually set by the HTML markup already and
so dynamic code implicitly changing it to something else doesn't make
much sense.
The code was taken straight from Sdl2Application where it assumed the
main render loop polls for canvas size changes and so it would pick it
up automagically. Not the case here, so the viewport event was never
fired after this.
By mistake I thought it's the same as in Emscripten's SDL, but there
Emscripten does some emulation to ensure windowSize() ==
framebufferSize().
For the resize event it's possible to hook into the window resize
callback instead of polling for the size every frame, That's much more
efficient.
Vladimír Vondruš