|
|
|
|
/*
|
|
|
|
|
This file is part of Magnum.
|
|
|
|
|
|
|
|
|
|
Copyright © 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019
|
|
|
|
|
Vladimír Vondruš <mosra@centrum.cz>
|
|
|
|
|
Copyright © 2019 Marco Melorio <m.melorio@icloud.com>
|
|
|
|
|
|
|
|
|
|
Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
to deal in the Software without restriction, including without limitation
|
|
|
|
|
the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
|
|
|
|
|
The above copyright notice and this permission notice shall be included
|
|
|
|
|
in all copies or substantial portions of the Software.
|
|
|
|
|
|
|
|
|
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
|
DEALINGS IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "Sdl2Application.h"
|
|
|
|
|
|
|
|
|
|
#include <cstring>
|
|
|
|
|
#ifdef CORRADE_TARGET_CLANG_CL
|
|
|
|
|
/* SDL does #pragma pack(push,8) and #pragma pack(pop,8) in different headers
|
|
|
|
|
(begin_code.h and end_code.h) and clang-cl doesn't like that, even though it
|
|
|
|
|
is completely fine. Silence the warning. */
|
|
|
|
|
#pragma clang diagnostic push
|
|
|
|
|
#pragma clang diagnostic ignored "-Wpragma-pack"
|
|
|
|
|
#endif
|
|
|
|
|
#include <SDL.h>
|
|
|
|
|
#ifdef CORRADE_TARGET_CLANG_CL
|
|
|
|
|
#pragma clang diagnostic pop
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
#include <tuple>
|
|
|
|
|
#else
|
|
|
|
|
#include <emscripten/emscripten.h>
|
|
|
|
|
#include <emscripten/html5.h>
|
|
|
|
|
#endif
|
|
|
|
|
#include <Corrade/Utility/Arguments.h>
|
|
|
|
|
|
|
|
|
|
#include "Magnum/ImageView.h"
|
|
|
|
|
#include "Magnum/PixelFormat.h"
|
|
|
|
|
#include "Magnum/Math/ConfigurationValue.h"
|
|
|
|
|
#include "Magnum/Math/FunctionsBatch.h"
|
|
|
|
|
#include "Magnum/Math/Range.h"
|
|
|
|
|
#include "Magnum/Platform/ScreenedApplication.hpp"
|
|
|
|
|
#include "Magnum/Platform/Implementation/DpiScaling.h"
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
#include "Magnum/GL/Version.h"
|
|
|
|
|
#include "Magnum/Platform/GLContext.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
namespace Magnum { namespace Platform {
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fix up the modifiers -- we want >= operator to work properly on Shift,
|
|
|
|
|
* Ctrl, Alt, but SDL generates different event for left / right keys, thus
|
|
|
|
|
* (modifiers >= Shift) would pass only if both left and right were pressed,
|
|
|
|
|
* which is usually not what the developers wants.
|
|
|
|
|
*/
|
|
|
|
|
Sdl2Application::InputEvent::Modifiers fixedModifiers(Uint16 mod) {
|
|
|
|
|
Sdl2Application::InputEvent::Modifiers modifiers(static_cast<Sdl2Application::InputEvent::Modifier>(mod));
|
|
|
|
|
if(modifiers & Sdl2Application::InputEvent::Modifier::Shift) modifiers |= Sdl2Application::InputEvent::Modifier::Shift;
|
|
|
|
|
if(modifiers & Sdl2Application::InputEvent::Modifier::Ctrl) modifiers |= Sdl2Application::InputEvent::Modifier::Ctrl;
|
|
|
|
|
if(modifiers & Sdl2Application::InputEvent::Modifier::Alt) modifiers |= Sdl2Application::InputEvent::Modifier::Alt;
|
|
|
|
|
if(modifiers & Sdl2Application::InputEvent::Modifier::Super) modifiers |= Sdl2Application::InputEvent::Modifier::Alt;
|
|
|
|
|
return modifiers;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
enum class Sdl2Application::Flag: UnsignedByte {
|
|
|
|
|
Redraw = 1 << 0,
|
|
|
|
|
VSyncEnabled = 1 << 1,
|
|
|
|
|
NoTickEvent = 1 << 2,
|
|
|
|
|
NoAnyEvent = 1 << 3,
|
|
|
|
|
Exit = 1 << 4,
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
TextInputActive = 1 << 5,
|
|
|
|
|
Resizable = 1 << 6,
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef CORRADE_TARGET_APPLE
|
|
|
|
|
HiDpiWarningPrinted = 1 << 7
|
|
|
|
|
#endif
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Sdl2Application(const Arguments& arguments): Sdl2Application{arguments, Configuration{}} {}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Sdl2Application(const Arguments& arguments, const Configuration& configuration): Sdl2Application{arguments, NoCreate} {
|
|
|
|
|
create(configuration);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
Sdl2Application::Sdl2Application(const Arguments& arguments, const Configuration& configuration, const GLConfiguration& glConfiguration): Sdl2Application{arguments, NoCreate} {
|
|
|
|
|
create(configuration, glConfiguration);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Sdl2Application(const Arguments& arguments, NoCreateT):
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
_minimalLoopPeriod{0},
|
|
|
|
|
#endif
|
|
|
|
|
_flags{Flag::Redraw}
|
|
|
|
|
{
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
Utility::Arguments args{Implementation::windowScalingArguments()};
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
_context.reset(new GLContext{NoCreate, args, arguments.argc, arguments.argv});
|
|
|
|
|
#else
|
|
|
|
|
/** @todo this is duplicated here and in GlfwApplication, figure out a nice
|
|
|
|
|
non-duplicated way to handle this */
|
|
|
|
|
args.addOption("log", "default").setHelp("log", "console logging", "default|quiet|verbose")
|
|
|
|
|
.setFromEnvironment("log")
|
|
|
|
|
.parse(arguments.argc, arguments.argv);
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Available since 2.0.4, disables interception of SIGINT and SIGTERM so
|
|
|
|
|
it's possible to Ctrl-C the application even if exitEvent() doesn't set
|
|
|
|
|
event.setAccepted(). */
|
|
|
|
|
#ifdef SDL_HINT_NO_SIGNAL_HANDLERS
|
|
|
|
|
SDL_SetHint(SDL_HINT_NO_SIGNAL_HANDLERS, "1");
|
|
|
|
|
#endif
|
|
|
|
|
/* Available since 2.0.6, uses dedicated OpenGL ES drivers by default and a
|
|
|
|
|
desktop GLES context only if MAGNUM_TARGET_DESKTOP_GLES is defined as
|
|
|
|
|
well. */
|
|
|
|
|
#if !defined(MAGNUM_TARGET_DESKTOP_GLES) && defined(SDL_HINT_OPENGL_ES_DRIVER)
|
|
|
|
|
SDL_SetHint(SDL_HINT_OPENGL_ES_DRIVER, "1");
|
|
|
|
|
#endif
|
|
|
|
|
/* Available since 2.0.8, disables compositor bypass on X11, which causes
|
|
|
|
|
flickering on KWin as the compositor gets shut down on every startup */
|
|
|
|
|
#ifdef SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR
|
|
|
|
|
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR, "0");
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if(SDL_Init(SDL_INIT_VIDEO) < 0) {
|
|
|
|
|
Error() << "Cannot initialize SDL:" << SDL_GetError();
|
|
|
|
|
std::exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Save command-line arguments */
|
|
|
|
|
if(args.value("log") == "verbose") _verboseLog = true;
|
|
|
|
|
const std::string dpiScaling = args.value("dpi-scaling");
|
|
|
|
|
if(dpiScaling == "default")
|
|
|
|
|
_commandLineDpiScalingPolicy = Implementation::Sdl2DpiScalingPolicy::Default;
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#ifdef CORRADE_TARGET_APPLE
|
|
|
|
|
else if(dpiScaling == "framebuffer")
|
|
|
|
|
_commandLineDpiScalingPolicy = Implementation::Sdl2DpiScalingPolicy::Framebuffer;
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
#ifndef CORRADE_TARGET_APPLE
|
|
|
|
|
#if !defined(CORRADE_TARGET_EMSCRIPTEN) && !defined(CORRADE_TARGET_ANDROID)
|
|
|
|
|
else if(dpiScaling == "virtual")
|
|
|
|
|
_commandLineDpiScalingPolicy = Implementation::Sdl2DpiScalingPolicy::Virtual;
|
|
|
|
|
#endif
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
else if(dpiScaling == "physical")
|
|
|
|
|
_commandLineDpiScalingPolicy = Implementation::Sdl2DpiScalingPolicy::Physical;
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
else if(dpiScaling.find_first_of(" \t\n") != std::string::npos)
|
|
|
|
|
_commandLineDpiScaling = args.value<Vector2>("dpi-scaling");
|
|
|
|
|
else
|
|
|
|
|
_commandLineDpiScaling = Vector2{args.value<Float>("dpi-scaling")};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::create() {
|
|
|
|
|
create(Configuration{});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::create(const Configuration& configuration) {
|
|
|
|
|
if(!tryCreate(configuration)) std::exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
void Sdl2Application::create(const Configuration& configuration, const GLConfiguration& glConfiguration) {
|
|
|
|
|
if(!tryCreate(configuration, glConfiguration)) std::exit(1);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
Vector2 Sdl2Application::dpiScaling(const Configuration& configuration) {
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
std::ostream* verbose = _verboseLog ? Debug::output() : nullptr;
|
|
|
|
|
|
|
|
|
|
/* Print a helpful warning in case some extra steps are needed for HiDPI
|
|
|
|
|
support */
|
|
|
|
|
#ifdef CORRADE_TARGET_APPLE
|
|
|
|
|
if(!Implementation::isAppleBundleHiDpiEnabled() && !(_flags & Flag::HiDpiWarningPrinted)) {
|
|
|
|
|
Warning{} << "Platform::Sdl2Application: warning: the executable is not a HiDPI-enabled app bundle";
|
|
|
|
|
_flags |= Flag::HiDpiWarningPrinted;
|
|
|
|
|
}
|
|
|
|
|
#elif defined(CORRADE_TARGET_WINDOWS)
|
|
|
|
|
/* Handled below, warning printed only when using virtual DPI scaling */
|
|
|
|
|
#endif
|
|
|
|
|
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Use values from the configuration only if not overriden on command line.
|
|
|
|
|
In any case explicit scaling has a precedence before the policy. */
|
|
|
|
|
Implementation::Sdl2DpiScalingPolicy dpiScalingPolicy{};
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
if(!_commandLineDpiScaling.isZero()) {
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: user-defined DPI scaling" << _commandLineDpiScaling.x();
|
|
|
|
|
return _commandLineDpiScaling;
|
|
|
|
|
} else if(UnsignedByte(_commandLineDpiScalingPolicy)) {
|
|
|
|
|
dpiScalingPolicy = _commandLineDpiScalingPolicy;
|
|
|
|
|
} else if(!configuration.dpiScaling().isZero()) {
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: app-defined DPI scaling" << _commandLineDpiScaling.x();
|
|
|
|
|
return configuration.dpiScaling();
|
|
|
|
|
} else {
|
|
|
|
|
dpiScalingPolicy = configuration.dpiScalingPolicy();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* There's no choice on Apple, it's all controlled by the plist file. So
|
|
|
|
|
unless someone specified custom scaling via config or command-line
|
|
|
|
|
above, return the default. */
|
|
|
|
|
#ifdef CORRADE_TARGET_APPLE
|
|
|
|
|
return Vector2{1.0f};
|
|
|
|
|
|
|
|
|
|
/* Otherwise there's a choice between virtual and physical DPI scaling */
|
|
|
|
|
#else
|
|
|
|
|
/* Try to get virtual DPI scaling first, if supported and requested */
|
|
|
|
|
#if !defined(CORRADE_TARGET_EMSCRIPTEN) && !defined(CORRADE_TARGET_ANDROID)
|
|
|
|
|
if(dpiScalingPolicy == Implementation::Sdl2DpiScalingPolicy::Virtual) {
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Use Xft.dpi on X11 */
|
|
|
|
|
#ifdef _MAGNUM_PLATFORM_USE_X11
|
|
|
|
|
const Vector2 dpiScaling{Implementation::x11DpiScaling()};
|
|
|
|
|
if(!dpiScaling.isZero()) {
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: virtual DPI scaling" << dpiScaling.x();
|
|
|
|
|
return dpiScaling;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check for DPI awareness on (non-RT) Windows and then ask for DPI.
|
|
|
|
|
SDL_GetDisplayDPI() is querying GetDpiForMonitor() --
|
|
|
|
|
https://github.com/spurious/SDL-mirror/blob/17af4584cb28cdb3c2feba17e7d989a806007d9f/src/video/windows/SDL_windowsmodes.c#L266
|
|
|
|
|
and GetDpiForMonitor() returns 96 if the application is DPI unaware.
|
|
|
|
|
So we instead check for DPI awareness first (and tell the user if
|
|
|
|
|
not), and only if the app is, then we use SDL_GetDisplayDPI(). If
|
|
|
|
|
it's for some reason desired to get the DPI value unconditionally,
|
|
|
|
|
the user should use physical DPI scaling instead. */
|
|
|
|
|
#elif defined(CORRADE_TARGET_WINDOWS) && !defined(CORRADE_TARGET_WINDOWS_RT)
|
|
|
|
|
if(!Implementation::isWindowsAppDpiAware()) {
|
|
|
|
|
Warning{verbose} << "Platform::Sdl2Application: your application is not set as DPI-aware, DPI scaling won't be used";
|
|
|
|
|
return Vector2{1.0f};
|
|
|
|
|
}
|
|
|
|
|
Vector2 dpi;
|
|
|
|
|
if(SDL_GetDisplayDPI(0, nullptr, &dpi.x(), &dpi.y()) == 0) {
|
|
|
|
|
const Vector2 dpiScaling{dpi/96.0f};
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: virtual DPI scaling" << dpiScaling;
|
|
|
|
|
return dpiScaling;
|
|
|
|
|
}
|
|
|
|
|
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Otherwise ¯\_(ツ)_/¯ */
|
|
|
|
|
#else
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: sorry, virtual DPI scaling not implemented on this platform yet, falling back to physical DPI scaling";
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* At this point, either the virtual DPI query failed or a physical DPI
|
|
|
|
|
scaling is requested */
|
|
|
|
|
#if !defined(CORRADE_TARGET_EMSCRIPTEN) && !defined(CORRADE_TARGET_ANDROID)
|
|
|
|
|
CORRADE_INTERNAL_ASSERT(dpiScalingPolicy == Implementation::Sdl2DpiScalingPolicy::Virtual || dpiScalingPolicy == Implementation::Sdl2DpiScalingPolicy::Physical);
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#else
|
|
|
|
|
CORRADE_INTERNAL_ASSERT(dpiScalingPolicy == Implementation::Sdl2DpiScalingPolicy::Physical);
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Take device pixel ratio on Emscripten */
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
const Vector2 dpiScaling{Implementation::emscriptenDpiScaling()};
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: physical DPI scaling" << dpiScaling.x();
|
|
|
|
|
return dpiScaling;
|
|
|
|
|
|
|
|
|
|
/* Take display DPI elsewhere. Enable only on Linux (where it gets the
|
|
|
|
|
usually very-off value from X11) and on non-RT Windows (where it takes
|
|
|
|
|
the UI scale value like with virtual DPI scaling, but without checking
|
|
|
|
|
for DPI awareness first). Also only since SDL 2.0.4. */
|
|
|
|
|
#elif (defined(CORRADE_TARGET_UNIX) || (defined(CORRADE_TARGET_WINDOWS) && !defined(CORRADE_TARGET_WINDOWS_RT))) && SDL_VERSION_ATLEAST(2, 0, 4)
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
Vector2 dpi;
|
|
|
|
|
if(SDL_GetDisplayDPI(0, nullptr, &dpi.x(), &dpi.y()) == 0) {
|
|
|
|
|
const Vector2 dpiScaling{dpi/96.0f};
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: physical DPI scaling" << dpiScaling;
|
|
|
|
|
return dpiScaling;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Warning{} << "Platform::Sdl2Application: can't get physical display DPI, falling back to no scaling:" << SDL_GetError();
|
|
|
|
|
return Vector2{1.0f};
|
|
|
|
|
|
|
|
|
|
/* Not implemented otherwise */
|
|
|
|
|
#else
|
|
|
|
|
Debug{verbose} << "Platform::Sdl2Application: sorry, physical DPI scaling not implemented on this platform yet";
|
|
|
|
|
return Vector2{1.0f};
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::setWindowTitle(const std::string& title) {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_SetWindowTitle(_window, title.data());
|
|
|
|
|
#else
|
|
|
|
|
/* We don't have the _window because SDL_CreateWindow() doesn't exist in
|
|
|
|
|
the SDL1/2 hybrid. But it's not used anyway, so pass nullptr there. */
|
|
|
|
|
SDL_SetWindowTitle(nullptr, title.data());
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if !defined(CORRADE_TARGET_EMSCRIPTEN) && SDL_MAJOR_VERSION*1000 + SDL_MINOR_VERSION*100 + SDL_PATCHLEVEL >= 2005
|
|
|
|
|
void Sdl2Application::setWindowIcon(const ImageView2D& image) {
|
|
|
|
|
Uint32 format; /** @todo handle sRGB differently? */
|
|
|
|
|
switch(image.format()) {
|
|
|
|
|
case PixelFormat::RGB8Srgb:
|
|
|
|
|
case PixelFormat::RGB8Unorm:
|
|
|
|
|
format = SDL_PIXELFORMAT_RGB24;
|
|
|
|
|
break;
|
|
|
|
|
case PixelFormat::RGBA8Srgb:
|
|
|
|
|
case PixelFormat::RGBA8Unorm:
|
|
|
|
|
format = SDL_PIXELFORMAT_RGBA32;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
CORRADE_ASSERT(false, "Platform::Sdl2Application::setWindowIcon(): unexpected format" << image.format(), );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Images are loaded with origin at bottom left, flip it to top left.
|
|
|
|
|
Fortunately SDL accepts negative stride, so we don't need to do an
|
|
|
|
|
expensive flip ourselves. */
|
|
|
|
|
Containers::StridedArrayView3D<const char> pixels = image.pixels().flipped<0>();
|
|
|
|
|
SDL_Surface* icon = SDL_CreateRGBSurfaceWithFormatFrom(const_cast<void*>(pixels.data()) , image.size().x(), image.size().y(), 32, pixels.stride()[0], format);
|
|
|
|
|
SDL_SetWindowIcon(_window, icon);
|
|
|
|
|
SDL_FreeSurface(icon);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
bool Sdl2Application::tryCreate(const Configuration& configuration) {
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
if(!(configuration.windowFlags() & Configuration::WindowFlag::Contextless))
|
|
|
|
|
return tryCreate(configuration, GLConfiguration{});
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Scale window based on DPI */
|
|
|
|
|
_dpiScaling = dpiScaling(configuration);
|
|
|
|
|
const Vector2i scaledWindowSize = configuration.size()*_dpiScaling;
|
|
|
|
|
|
|
|
|
|
/* Create window */
|
|
|
|
|
if(!(_window = SDL_CreateWindow(
|
|
|
|
|
#ifndef CORRADE_TARGET_IOS
|
|
|
|
|
configuration.title().data(),
|
|
|
|
|
#else
|
|
|
|
|
nullptr,
|
|
|
|
|
#endif
|
|
|
|
|
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
scaledWindowSize.x(), scaledWindowSize.y(),
|
|
|
|
|
SDL_WINDOW_ALLOW_HIGHDPI|SDL_WINDOW_OPENGL|Uint32(configuration.windowFlags() & ~Configuration::WindowFlag::Contextless))))
|
|
|
|
|
{
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create window:" << SDL_GetError();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Emscripten-specific initialization */
|
|
|
|
|
#else
|
|
|
|
|
/* Get CSS canvas size. This is used later to detect canvas resizes and
|
|
|
|
|
fire viewport events, because Emscripten doesn't do that. Related info:
|
|
|
|
|
https://github.com/kripken/emscripten/issues/1731 */
|
|
|
|
|
/** @todo don't hardcode "#canvas" here, make it configurable from outside */
|
|
|
|
|
{
|
|
|
|
|
Vector2d canvasSize;
|
|
|
|
|
/* Emscripten 1.38.27 changed to generic CSS selectors from element
|
|
|
|
|
IDs depending on -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1
|
|
|
|
|
being set (which we can't detect at compile time). Fortunately,
|
|
|
|
|
using #canvas works the same way both in the previous versions and
|
|
|
|
|
the current one. Unfortunately, this is also the only value that
|
|
|
|
|
works the same way for both. Further details at
|
|
|
|
|
https://github.com/emscripten-core/emscripten/pull/7977 */
|
|
|
|
|
emscripten_get_element_css_size("#canvas", &canvasSize.x(), &canvasSize.y());
|
|
|
|
|
_lastKnownCanvasSize = Vector2i{canvasSize};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* By default Emscripten creates a 300x150 canvas. That's so freaking
|
|
|
|
|
random I'm getting mad. Use the real (CSS pixels) canvas size instead,
|
|
|
|
|
if the size is not hardcoded from the configuration. This is then
|
|
|
|
|
multiplied by the DPI scaling. */
|
|
|
|
|
Vector2i windowSize;
|
|
|
|
|
if(!configuration.size().isZero()) {
|
|
|
|
|
windowSize = configuration.size();
|
|
|
|
|
} else {
|
|
|
|
|
windowSize = _lastKnownCanvasSize;
|
|
|
|
|
Debug{_verboseLog ? Debug::output() : nullptr} << "Platform::Sdl2Application::tryCreate(): autodetected canvas size" << windowSize;
|
|
|
|
|
}
|
|
|
|
|
_dpiScaling = dpiScaling(configuration);
|
|
|
|
|
const Vector2i scaledWindowSize = windowSize*_dpiScaling;
|
|
|
|
|
|
|
|
|
|
Uint32 flags = SDL_OPENGL|SDL_HWSURFACE|SDL_DOUBLEBUF;
|
|
|
|
|
if(configuration.windowFlags() & Configuration::WindowFlag::Resizable) {
|
|
|
|
|
_flags |= Flag::Resizable;
|
|
|
|
|
/* Actually not sure if this makes any difference:
|
|
|
|
|
https://github.com/kripken/emscripten/issues/1731 */
|
|
|
|
|
flags |= SDL_RESIZABLE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(!(_surface = SDL_SetVideoMode(scaledWindowSize.x(), scaledWindowSize.y(), 24, flags))) {
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create context:" << SDL_GetError();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
bool Sdl2Application::tryCreate(const Configuration& configuration, const GLConfiguration& glConfiguration) {
|
|
|
|
|
CORRADE_ASSERT(_context->version() == GL::Version::None, "Platform::Sdl2Application::tryCreate(): context already created", false);
|
|
|
|
|
|
|
|
|
|
/* Enable double buffering, set up buffer sizes */
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, glConfiguration.colorBufferSize().r());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, glConfiguration.colorBufferSize().g());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, glConfiguration.colorBufferSize().b());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, glConfiguration.colorBufferSize().a());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, glConfiguration.depthBufferSize());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_STENCIL_SIZE, glConfiguration.stencilBufferSize());
|
|
|
|
|
|
|
|
|
|
/* Multisampling */
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, glConfiguration.sampleCount() > 1 ? 1 : 0);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, glConfiguration.sampleCount());
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* sRGB */
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_FRAMEBUFFER_SRGB_CAPABLE, glConfiguration.isSrgbCapable());
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/** @todo Remove when Emscripten has proper SDL2 support */
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
/* Scale window based on DPI */
|
|
|
|
|
_dpiScaling = dpiScaling(configuration);
|
|
|
|
|
const Vector2i scaledWindowSize = configuration.size()*_dpiScaling;
|
|
|
|
|
|
|
|
|
|
/* Request debug context if --magnum-gpu-validation is enabled */
|
|
|
|
|
GLConfiguration::Flags glFlags = glConfiguration.flags();
|
|
|
|
|
if(_context->internalFlags() & GL::Context::InternalFlag::GpuValidation)
|
|
|
|
|
glFlags |= GLConfiguration::Flag::Debug;
|
|
|
|
|
|
|
|
|
|
/* Set context version, if user-specified */
|
|
|
|
|
if(glConfiguration.version() != GL::Version::None) {
|
|
|
|
|
Int major, minor;
|
|
|
|
|
std::tie(major, minor) = version(glConfiguration.version());
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, major);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, minor);
|
|
|
|
|
|
|
|
|
|
#ifndef MAGNUM_TARGET_GLES
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, glConfiguration.version() >= GL::Version::GL310 ?
|
|
|
|
|
SDL_GL_CONTEXT_PROFILE_CORE : SDL_GL_CONTEXT_PROFILE_COMPATIBILITY);
|
|
|
|
|
#else
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, int(glFlags));
|
|
|
|
|
|
|
|
|
|
/* Request usable version otherwise */
|
|
|
|
|
} else {
|
|
|
|
|
#ifndef MAGNUM_TARGET_GLES
|
|
|
|
|
/* First try to create core context. This is needed mainly on macOS and
|
|
|
|
|
Mesa, as support for recent OpenGL versions isn't implemented in
|
|
|
|
|
compatibility contexts (which are the default). At least GL 3.2 is
|
|
|
|
|
needed on macOS, at least GL 3.1 is needed on Mesa. Bite the bullet
|
|
|
|
|
and try 3.1 also elsewhere. */
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
|
|
|
|
|
#ifdef CORRADE_TARGET_APPLE
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
|
|
|
|
|
#else
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
|
|
|
|
|
#endif
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, int(glFlags));
|
|
|
|
|
#else
|
|
|
|
|
/* For ES the major context version is compile-time constant */
|
|
|
|
|
#ifdef MAGNUM_TARGET_GLES3
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
|
|
|
|
|
#elif defined(MAGNUM_TARGET_GLES2)
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
|
|
|
|
|
#else
|
|
|
|
|
#error unsupported OpenGL ES version
|
|
|
|
|
#endif
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create window. Hide it by default so we don't have distracting window
|
|
|
|
|
blinking in case we have to destroy it again right away */
|
|
|
|
|
if(!(_window = SDL_CreateWindow(
|
|
|
|
|
#ifndef CORRADE_TARGET_IOS
|
|
|
|
|
configuration.title().data(),
|
|
|
|
|
#else
|
|
|
|
|
nullptr,
|
|
|
|
|
#endif
|
|
|
|
|
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
scaledWindowSize.x(), scaledWindowSize.y(),
|
|
|
|
|
SDL_WINDOW_OPENGL|SDL_WINDOW_HIDDEN|SDL_WINDOW_ALLOW_HIGHDPI|Uint32(configuration.windowFlags()))))
|
|
|
|
|
{
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create window:" << SDL_GetError();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create context */
|
|
|
|
|
_glContext = SDL_GL_CreateContext(_window);
|
|
|
|
|
|
|
|
|
|
#ifndef MAGNUM_TARGET_GLES
|
|
|
|
|
/* Fall back to (forward compatible) GL 2.1, if version is not
|
|
|
|
|
user-specified and either core context creation fails or we are on
|
|
|
|
|
binary NVidia/AMD drivers on Linux/Windows or Intel Windows drivers.
|
|
|
|
|
Instead of creating forward-compatible context with highest available
|
|
|
|
|
version, they force the version to the one specified, which is
|
|
|
|
|
completely useless behavior. */
|
|
|
|
|
#ifndef CORRADE_TARGET_APPLE
|
|
|
|
|
constexpr static const char nvidiaVendorString[] = "NVIDIA Corporation";
|
|
|
|
|
#ifdef CORRADE_TARGET_WINDOWS
|
|
|
|
|
constexpr static const char intelVendorString[] = "Intel";
|
|
|
|
|
#endif
|
|
|
|
|
constexpr static const char amdVendorString[] = "ATI Technologies Inc.";
|
|
|
|
|
const char* vendorString;
|
|
|
|
|
#endif
|
|
|
|
|
if(glConfiguration.version() == GL::Version::None && (!_glContext
|
|
|
|
|
#ifndef CORRADE_TARGET_APPLE
|
|
|
|
|
/* If context creation fails *really bad*, glGetString() may actually
|
|
|
|
|
return nullptr. Check for that to avoid crashes deep inside
|
|
|
|
|
strncmp(). Sorry about the UGLY code, HOPEFULLY THERE WON'T BE MORE
|
|
|
|
|
WORKAROUNDS */
|
|
|
|
|
|| (vendorString = reinterpret_cast<const char*>(glGetString(GL_VENDOR)),
|
|
|
|
|
vendorString && (std::strncmp(vendorString, nvidiaVendorString, sizeof(nvidiaVendorString)) == 0 ||
|
|
|
|
|
#ifdef CORRADE_TARGET_WINDOWS
|
|
|
|
|
std::strncmp(vendorString, intelVendorString, sizeof(intelVendorString)) == 0 ||
|
|
|
|
|
#endif
|
|
|
|
|
std::strncmp(vendorString, amdVendorString, sizeof(amdVendorString)) == 0)
|
|
|
|
|
&& !_context->isDriverWorkaroundDisabled("no-forward-compatible-core-context"))
|
|
|
|
|
#endif
|
|
|
|
|
)) {
|
|
|
|
|
/* Don't print any warning when doing the workaround, because the bug
|
|
|
|
|
will be there probably forever */
|
|
|
|
|
if(!_glContext) Warning()
|
|
|
|
|
<< "Platform::Sdl2Application::tryCreate(): cannot create core context:"
|
|
|
|
|
<< SDL_GetError() << "(falling back to compatibility context)";
|
|
|
|
|
else SDL_GL_DeleteContext(_glContext);
|
|
|
|
|
|
|
|
|
|
SDL_DestroyWindow(_window);
|
|
|
|
|
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_COMPATIBILITY);
|
|
|
|
|
/** @todo or keep the fwcompat? */
|
|
|
|
|
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, int(glFlags) & int(~GLConfiguration::Flag::ForwardCompatible));
|
|
|
|
|
|
|
|
|
|
if(!(_window = SDL_CreateWindow(configuration.title().data(),
|
|
|
|
|
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
scaledWindowSize.x(), scaledWindowSize.y(),
|
|
|
|
|
SDL_WINDOW_OPENGL|SDL_WINDOW_HIDDEN|SDL_WINDOW_ALLOW_HIGHDPI|Uint32(configuration.windowFlags()&~Configuration::WindowFlag::Contextless))))
|
|
|
|
|
{
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create window:" << SDL_GetError();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create compatibility context */
|
|
|
|
|
_glContext = SDL_GL_CreateContext(_window);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Cannot create context (or fallback compatibility context on desktop) */
|
|
|
|
|
if(!_glContext) {
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create context:" << SDL_GetError();
|
|
|
|
|
SDL_DestroyWindow(_window);
|
|
|
|
|
_window = nullptr;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef CORRADE_TARGET_IOS
|
|
|
|
|
/* iOS has zero initial GL_VIEWPORT size, get drawable size and put it back
|
|
|
|
|
in so all other code can assume that the viewport is set to sane values.
|
|
|
|
|
Fortunately on iOS we also don't have to load any function pointers so
|
|
|
|
|
it's safe to do the glViewport() call as it is linked statically. */
|
|
|
|
|
{
|
|
|
|
|
const Vector2i viewport = framebufferSize();
|
|
|
|
|
glViewport(0, 0, viewport.x(), viewport.y());
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Emscripten-specific initialization */
|
|
|
|
|
#else
|
|
|
|
|
/* Get CSS canvas size. This is used later to detect canvas resizes and
|
|
|
|
|
fire viewport events, because Emscripten doesn't do that. Related info:
|
|
|
|
|
https://github.com/kripken/emscripten/issues/1731 */
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
/** @todo don't hardcode "#canvas" here, make it configurable from outside */
|
|
|
|
|
{
|
|
|
|
|
Vector2d canvasSize;
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
/* Emscripten 1.38.27 changed to generic CSS selectors from element
|
|
|
|
|
IDs depending on -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1
|
|
|
|
|
being set (which we can't detect at compile time). Fortunately,
|
|
|
|
|
using #canvas works the same way both in the previous versions and
|
|
|
|
|
the current one. Unfortunately, this is also the only value that
|
|
|
|
|
works the same way for both. Further details at
|
|
|
|
|
https://github.com/emscripten-core/emscripten/pull/7977 */
|
|
|
|
|
emscripten_get_element_css_size("#canvas", &canvasSize.x(), &canvasSize.y());
|
|
|
|
|
_lastKnownCanvasSize = Vector2i{canvasSize};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* By default Emscripten creates a 300x150 canvas. That's so freaking
|
|
|
|
|
random I'm getting mad. Use the real (CSS pixels) canvas size instead,
|
|
|
|
|
if the size is not hardcoded from the configuration. This is then
|
|
|
|
|
multiplied by the DPI scaling. */
|
|
|
|
|
Vector2i windowSize;
|
|
|
|
|
if(!configuration.size().isZero()) {
|
|
|
|
|
windowSize = configuration.size();
|
|
|
|
|
} else {
|
|
|
|
|
windowSize = _lastKnownCanvasSize;
|
|
|
|
|
Debug{_verboseLog ? Debug::output() : nullptr} << "Platform::Sdl2Application::tryCreate(): autodetected canvas size" << windowSize;
|
|
|
|
|
}
|
|
|
|
|
_dpiScaling = dpiScaling(configuration);
|
|
|
|
|
const Vector2i scaledWindowSize = windowSize*_dpiScaling;
|
|
|
|
|
|
|
|
|
|
Uint32 flags = SDL_OPENGL|SDL_HWSURFACE|SDL_DOUBLEBUF;
|
|
|
|
|
if(configuration.windowFlags() & Configuration::WindowFlag::Resizable) {
|
|
|
|
|
_flags |= Flag::Resizable;
|
|
|
|
|
/* Actually not sure if this makes any difference:
|
|
|
|
|
https://github.com/kripken/emscripten/issues/1731 */
|
|
|
|
|
flags |= SDL_RESIZABLE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(!(_surface = SDL_SetVideoMode(scaledWindowSize.x(), scaledWindowSize.y(), 24, flags))) {
|
|
|
|
|
Error() << "Platform::Sdl2Application::tryCreate(): cannot create context:" << SDL_GetError();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Destroy everything also when the Magnum context creation fails */
|
|
|
|
|
if(!_context->tryCreate()) {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_GL_DeleteContext(_glContext);
|
|
|
|
|
SDL_DestroyWindow(_window);
|
|
|
|
|
_window = nullptr;
|
|
|
|
|
#else
|
|
|
|
|
SDL_FreeSurface(_surface);
|
|
|
|
|
#endif
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* Show the window once we are sure that everything is okay */
|
|
|
|
|
if(!(configuration.windowFlags() & Configuration::WindowFlag::Hidden))
|
|
|
|
|
SDL_ShowWindow(_window);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Return true if the initialization succeeds */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
Vector2i Sdl2Application::windowSize() const {
|
|
|
|
|
Vector2i size;
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
CORRADE_ASSERT(_window, "Platform::Sdl2Application::windowSize(): no window opened", {});
|
|
|
|
|
SDL_GetWindowSize(_window, &size.x(), &size.y());
|
|
|
|
|
#else
|
|
|
|
|
CORRADE_ASSERT(_surface, "Platform::Sdl2Application::windowSize(): no window opened", {});
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
emscripten_get_canvas_element_size("#canvas", &size.x(), &size.y());
|
|
|
|
|
#endif
|
|
|
|
|
return size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
void Sdl2Application::setWindowSize(const Vector2i& size) {
|
|
|
|
|
CORRADE_ASSERT(_window, "Platform::Sdl2Application::setWindowSize(): no window opened", );
|
|
|
|
|
|
|
|
|
|
const Vector2i newSize = _dpiScaling*size;
|
|
|
|
|
SDL_SetWindowSize(_window, newSize.x(), newSize.y());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::setMinWindowSize(const Vector2i& size) {
|
|
|
|
|
CORRADE_ASSERT(_window, "Platform::Sdl2Application::setMinWindowSize(): no window opened", );
|
|
|
|
|
|
|
|
|
|
const Vector2i newSize = _dpiScaling*size;
|
|
|
|
|
SDL_SetWindowMinimumSize(_window, newSize.x(), newSize.y());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::setMaxWindowSize(const Vector2i& size) {
|
|
|
|
|
CORRADE_ASSERT(_window, "Platform::Sdl2Application::setMaxWindowSize(): no window opened", );
|
|
|
|
|
|
|
|
|
|
const Vector2i newSize = _dpiScaling*size;
|
|
|
|
|
SDL_SetWindowMaximumSize(_window, newSize.x(), newSize.y());
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
Vector2i Sdl2Application::framebufferSize() const {
|
|
|
|
|
Vector2i size;
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
CORRADE_ASSERT(_window, "Platform::Sdl2Application::framebufferSize(): no window opened", {});
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
SDL_GL_GetDrawableSize(_window, &size.x(), &size.y());
|
|
|
|
|
#else
|
|
|
|
|
CORRADE_ASSERT(_surface, "Platform::Sdl2Application::framebufferSize(): no window opened", {});
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
emscripten_get_canvas_element_size("#canvas", &size.x(), &size.y());
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
#endif
|
|
|
|
|
return size;
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
}
|
|
|
|
|
#endif
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
void Sdl2Application::setContainerCssClass(const std::string& cssClass) {
|
|
|
|
|
#pragma GCC diagnostic push
|
|
|
|
|
#pragma GCC diagnostic ignored "-Wdollar-in-identifier-extension"
|
|
|
|
|
EM_ASM_({document.getElementById('container').className = AsciiToString($0);}, cssClass.data());
|
|
|
|
|
#pragma GCC diagnostic pop
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::swapBuffers() {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_GL_SwapWindow(_window);
|
|
|
|
|
#else
|
|
|
|
|
SDL_Flip(_surface);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Int Sdl2Application::swapInterval() const {
|
|
|
|
|
return SDL_GL_GetSwapInterval();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Sdl2Application::setSwapInterval(const Int interval) {
|
|
|
|
|
if(SDL_GL_SetSwapInterval(interval) == -1) {
|
|
|
|
|
Error() << "Platform::Sdl2Application::setSwapInterval(): cannot set swap interval:" << SDL_GetError();
|
|
|
|
|
_flags &= ~Flag::VSyncEnabled;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(SDL_GL_GetSwapInterval() != interval) {
|
|
|
|
|
Error() << "Platform::Sdl2Application::setSwapInterval(): swap interval setting ignored by the driver";
|
|
|
|
|
_flags &= ~Flag::VSyncEnabled;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(interval) _flags |= Flag::VSyncEnabled;
|
|
|
|
|
else _flags &= ~Flag::VSyncEnabled;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::redraw() { _flags |= Flag::Redraw; }
|
|
|
|
|
|
|
|
|
|
Sdl2Application::~Sdl2Application() {
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
_context.reset();
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_GL_DeleteContext(_glContext);
|
|
|
|
|
#else
|
|
|
|
|
SDL_FreeSurface(_surface);
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
for(auto& cursor: _cursors)
|
|
|
|
|
SDL_FreeCursor(cursor);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_DestroyWindow(_window);
|
|
|
|
|
#endif
|
|
|
|
|
SDL_Quit();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int Sdl2Application::exec() {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
while(mainLoopIteration()) {}
|
|
|
|
|
#else
|
|
|
|
|
emscripten_set_main_loop_arg([](void* arg) {
|
|
|
|
|
static_cast<Sdl2Application*>(arg)->mainLoopIteration();
|
|
|
|
|
}, this, 0, true);
|
|
|
|
|
#endif
|
|
|
|
|
return _exitCode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::exit(const int exitCode) {
|
|
|
|
|
/* On Emscripten this flag is used only to indicate a desire to exit from
|
|
|
|
|
mainLoopIteration() */
|
|
|
|
|
_flags |= Flag::Exit;
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
emscripten_cancel_main_loop();
|
|
|
|
|
#endif
|
|
|
|
|
_exitCode = exitCode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Sdl2Application::mainLoopIteration() {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
const UnsignedInt timeBefore = _minimalLoopPeriod ? SDL_GetTicks() : 0;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* The resize event is not fired on window resize, so poll for the canvas
|
|
|
|
|
size here. But only if the window was requested to be resizable, to
|
|
|
|
|
avoid resizing the canvas when the user doesn't want that. Related
|
|
|
|
|
issue: https://github.com/kripken/emscripten/issues/1731 */
|
|
|
|
|
if(_flags & Flag::Resizable) {
|
|
|
|
|
Vector2d canvasSize;
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
/* Emscripten 1.38.27 changed to generic CSS selectors from element
|
|
|
|
|
IDs depending on -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1
|
|
|
|
|
being set (which we can't detect at compile time). See above for the
|
|
|
|
|
reason why we hardcode #canvas here. */
|
|
|
|
|
emscripten_get_element_css_size("#canvas", &canvasSize.x(), &canvasSize.y());
|
|
|
|
|
|
|
|
|
|
const Vector2i canvasSizei{canvasSize};
|
|
|
|
|
if(canvasSizei != _lastKnownCanvasSize) {
|
|
|
|
|
_lastKnownCanvasSize = canvasSizei;
|
|
|
|
|
const Vector2i size = _dpiScaling*canvasSizei;
|
Platforms: update Emscripten markup for 1.38.27 and up.
This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
7 years ago
|
|
|
emscripten_set_canvas_element_size("#canvas", size.x(), size.y());
|
|
|
|
|
ViewportEvent e{
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
size,
|
|
|
|
|
#endif
|
|
|
|
|
size, _dpiScaling};
|
|
|
|
|
viewportEvent(e);
|
|
|
|
|
_flags |= Flag::Redraw;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
SDL_Event event;
|
|
|
|
|
while(SDL_PollEvent(&event)) {
|
|
|
|
|
switch(event.type) {
|
|
|
|
|
case SDL_WINDOWEVENT:
|
|
|
|
|
switch(event.window.event) {
|
|
|
|
|
/* Not using SDL_WINDOWEVENT_RESIZED, because that doens't
|
|
|
|
|
get fired when the window is resized programmatically
|
|
|
|
|
(such as through setMaxWindowSize()) */
|
|
|
|
|
case SDL_WINDOWEVENT_SIZE_CHANGED: {
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* If anybody sees this assert, then emscripten finally
|
|
|
|
|
implemented resize events. Praise them for that.
|
|
|
|
|
https://github.com/kripken/emscripten/issues/1731 */
|
|
|
|
|
CORRADE_ASSERT_UNREACHABLE();
|
|
|
|
|
#else
|
|
|
|
|
/* {event.window.data1, event.window.data2} seems to be
|
|
|
|
|
framebuffer size and not window size on macOS, which
|
|
|
|
|
is weird. Query the values directly instead to be
|
|
|
|
|
really sure. */
|
|
|
|
|
ViewportEvent e{event, windowSize(),
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
framebufferSize(),
|
|
|
|
|
#endif
|
|
|
|
|
_dpiScaling};
|
|
|
|
|
/** @todo handle also WM_DPICHANGED events when a window is moved between displays with different DPI */
|
|
|
|
|
viewportEvent(e);
|
|
|
|
|
_flags |= Flag::Redraw;
|
|
|
|
|
#endif
|
|
|
|
|
} break;
|
|
|
|
|
/* Direct everything that wasn't exposed via a callback to
|
|
|
|
|
anyEvent(), so users can implement event handling for
|
|
|
|
|
things not present in the Application APIs */
|
|
|
|
|
case SDL_WINDOWEVENT_EXPOSED:
|
|
|
|
|
_flags |= Flag::Redraw;
|
|
|
|
|
if(!(_flags & Flag::NoAnyEvent)) anyEvent(event);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
if(!(_flags & Flag::NoAnyEvent)) anyEvent(event);
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case SDL_KEYDOWN:
|
|
|
|
|
case SDL_KEYUP: {
|
|
|
|
|
KeyEvent e{event, static_cast<KeyEvent::Key>(event.key.keysym.sym), fixedModifiers(event.key.keysym.mod), event.key.repeat != 0};
|
|
|
|
|
event.type == SDL_KEYDOWN ? keyPressEvent(e) : keyReleaseEvent(e);
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case SDL_MOUSEBUTTONDOWN:
|
|
|
|
|
case SDL_MOUSEBUTTONUP: {
|
|
|
|
|
MouseEvent e{event, static_cast<MouseEvent::Button>(event.button.button), {event.button.x, event.button.y}
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
, event.button.clicks
|
|
|
|
|
#endif
|
|
|
|
|
};
|
|
|
|
|
event.type == SDL_MOUSEBUTTONDOWN ? mousePressEvent(e) : mouseReleaseEvent(e);
|
|
|
|
|
} break;
|
|
|
|
|
|
Platform: first-class MouseScrollEvent for SDL2 and NaCl application.
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
10 years ago
|
|
|
case SDL_MOUSEWHEEL: {
|
|
|
|
|
MouseScrollEvent e{event, {Float(event.wheel.x), Float(event.wheel.y)}};
|
Platform: first-class MouseScrollEvent for SDL2 and NaCl application.
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
10 years ago
|
|
|
mouseScrollEvent(e);
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case SDL_MOUSEMOTION: {
|
|
|
|
|
MouseMoveEvent e{event, {event.motion.x, event.motion.y}, {event.motion.xrel, event.motion.yrel}, static_cast<MouseMoveEvent::Button>(event.motion.state)};
|
|
|
|
|
mouseMoveEvent(e);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case SDL_MULTIGESTURE: {
|
|
|
|
|
MultiGestureEvent e{event, {event.mgesture.x, event.mgesture.y}, event.mgesture.dTheta, event.mgesture.dDist, event.mgesture.numFingers};
|
|
|
|
|
multiGestureEvent(e);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case SDL_TEXTINPUT: {
|
|
|
|
|
TextInputEvent e{event, {event.text.text, std::strlen(event.text.text)}};
|
|
|
|
|
textInputEvent(e);
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case SDL_TEXTEDITING: {
|
|
|
|
|
TextEditingEvent e{event, {event.edit.text, std::strlen(event.text.text)}, event.edit.start, event.edit.length};
|
|
|
|
|
textEditingEvent(e);
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case SDL_QUIT: {
|
|
|
|
|
ExitEvent e{event};
|
|
|
|
|
exitEvent(e);
|
|
|
|
|
if(e.isAccepted()) {
|
|
|
|
|
/* On Emscripten this flag is used only to indicate a
|
|
|
|
|
desire to exit from mainLoopIteration() */
|
|
|
|
|
_flags |= Flag::Exit;
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
emscripten_cancel_main_loop();
|
|
|
|
|
#endif
|
|
|
|
|
return !(_flags & Flag::Exit);
|
|
|
|
|
}
|
|
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
/* Direct everything else to anyEvent(), so users can implement
|
|
|
|
|
event handling for things not present in the Application APIs */
|
|
|
|
|
default: if(!(_flags & Flag::NoAnyEvent)) anyEvent(event);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Tick event */
|
|
|
|
|
if(!(_flags & Flag::NoTickEvent)) tickEvent();
|
|
|
|
|
|
|
|
|
|
/* Draw event */
|
|
|
|
|
if(_flags & Flag::Redraw) {
|
|
|
|
|
_flags &= ~Flag::Redraw;
|
|
|
|
|
drawEvent();
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* If VSync is not enabled, delay to prevent CPU hogging (if set) */
|
|
|
|
|
if(!(_flags & Flag::VSyncEnabled) && _minimalLoopPeriod) {
|
|
|
|
|
const UnsignedInt loopTime = SDL_GetTicks() - timeBefore;
|
|
|
|
|
if(loopTime < _minimalLoopPeriod)
|
|
|
|
|
SDL_Delay(_minimalLoopPeriod - loopTime);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
return !(_flags & Flag::Exit);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
/* If not drawing anything, delay to prevent CPU hogging (if set) */
|
|
|
|
|
if(_minimalLoopPeriod) {
|
|
|
|
|
const UnsignedInt loopTime = SDL_GetTicks() - timeBefore;
|
|
|
|
|
if(loopTime < _minimalLoopPeriod)
|
|
|
|
|
SDL_Delay(_minimalLoopPeriod - loopTime);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Then, if the tick event doesn't need to be called periodically, wait
|
|
|
|
|
indefinitely for next input event */
|
|
|
|
|
if(_flags & Flag::NoTickEvent) SDL_WaitEvent(nullptr);
|
|
|
|
|
#endif
|
|
|
|
|
return !(_flags & Flag::Exit);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
constexpr SDL_SystemCursor CursorMap[] {
|
|
|
|
|
SDL_SYSTEM_CURSOR_ARROW,
|
|
|
|
|
SDL_SYSTEM_CURSOR_IBEAM,
|
|
|
|
|
SDL_SYSTEM_CURSOR_WAIT,
|
|
|
|
|
SDL_SYSTEM_CURSOR_CROSSHAIR,
|
|
|
|
|
SDL_SYSTEM_CURSOR_WAITARROW,
|
|
|
|
|
SDL_SYSTEM_CURSOR_SIZENWSE,
|
|
|
|
|
SDL_SYSTEM_CURSOR_SIZENESW,
|
|
|
|
|
SDL_SYSTEM_CURSOR_SIZEWE,
|
|
|
|
|
SDL_SYSTEM_CURSOR_SIZENS,
|
|
|
|
|
SDL_SYSTEM_CURSOR_SIZEALL,
|
|
|
|
|
SDL_SYSTEM_CURSOR_NO,
|
|
|
|
|
SDL_SYSTEM_CURSOR_HAND
|
|
|
|
|
};
|
|
|
|
|
#else
|
|
|
|
|
constexpr const char* CursorMap[] {
|
|
|
|
|
"default",
|
|
|
|
|
"text",
|
|
|
|
|
"wait",
|
|
|
|
|
"crosshair",
|
|
|
|
|
"progress",
|
|
|
|
|
"nwse-resize",
|
|
|
|
|
"nesw-resize",
|
|
|
|
|
"ew-resize",
|
|
|
|
|
"ns-resize",
|
|
|
|
|
"move",
|
|
|
|
|
"not-allowed",
|
|
|
|
|
"pointer",
|
|
|
|
|
"none"
|
|
|
|
|
/* Hidden & locked not supported yet */
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::setCursor(Cursor cursor) {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
CORRADE_INTERNAL_ASSERT(UnsignedInt(cursor) < Containers::arraySize(_cursors));
|
|
|
|
|
|
|
|
|
|
if(cursor == Cursor::Hidden) {
|
|
|
|
|
SDL_ShowCursor(SDL_DISABLE);
|
|
|
|
|
SDL_SetWindowGrab(_window, SDL_FALSE);
|
|
|
|
|
SDL_SetRelativeMouseMode(SDL_FALSE);
|
|
|
|
|
return;
|
|
|
|
|
} else if(cursor == Cursor::HiddenLocked) {
|
|
|
|
|
SDL_SetWindowGrab(_window, SDL_TRUE);
|
|
|
|
|
SDL_SetRelativeMouseMode(SDL_TRUE);
|
|
|
|
|
return;
|
|
|
|
|
} else {
|
|
|
|
|
SDL_ShowCursor(SDL_ENABLE);
|
|
|
|
|
SDL_SetWindowGrab(_window, SDL_FALSE);
|
|
|
|
|
SDL_SetRelativeMouseMode(SDL_FALSE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(!_cursors[UnsignedInt(cursor)])
|
|
|
|
|
_cursors[UnsignedInt(cursor)] = SDL_CreateSystemCursor(CursorMap[UnsignedInt(cursor)]);
|
|
|
|
|
|
|
|
|
|
SDL_SetCursor(_cursors[UnsignedInt(cursor)]);
|
|
|
|
|
#else
|
|
|
|
|
_cursor = cursor;
|
|
|
|
|
CORRADE_INTERNAL_ASSERT(UnsignedInt(cursor) < Containers::arraySize(CursorMap));
|
|
|
|
|
#pragma GCC diagnostic push
|
|
|
|
|
#pragma GCC diagnostic ignored "-Wdollar-in-identifier-extension"
|
|
|
|
|
EM_ASM_({document.getElementById('canvas').style.cursor = AsciiToString($0);}, CursorMap[UnsignedInt(cursor)]);
|
|
|
|
|
#pragma GCC diagnostic pop
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Cursor Sdl2Application::cursor() {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
if(SDL_GetRelativeMouseMode())
|
|
|
|
|
return Cursor::HiddenLocked;
|
|
|
|
|
else if(!SDL_ShowCursor(SDL_QUERY))
|
|
|
|
|
return Cursor::Hidden;
|
|
|
|
|
|
|
|
|
|
SDL_Cursor* cursor = SDL_GetCursor();
|
|
|
|
|
|
|
|
|
|
if(cursor) for(UnsignedInt i = 0; i < sizeof(_cursors); i++)
|
|
|
|
|
if(_cursors[i] == cursor) return Cursor(i);
|
|
|
|
|
|
|
|
|
|
return Cursor::Arrow;
|
|
|
|
|
#else
|
|
|
|
|
return _cursor;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_BUILD_DEPRECATED
|
|
|
|
|
void Sdl2Application::setMouseLocked(bool enabled) {
|
|
|
|
|
/** @todo Implement this in Emscripten */
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
SDL_SetWindowGrab(_window, enabled ? SDL_TRUE : SDL_FALSE);
|
|
|
|
|
SDL_SetRelativeMouseMode(enabled ? SDL_TRUE : SDL_FALSE);
|
|
|
|
|
#else
|
|
|
|
|
CORRADE_ASSERT(false, "Sdl2Application::setMouseLocked(): not implemented", );
|
|
|
|
|
static_cast<void>(enabled);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
bool Sdl2Application::isTextInputActive() {
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
return SDL_IsTextInputActive();
|
|
|
|
|
#else
|
|
|
|
|
return !!(_flags & Flag::TextInputActive);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::startTextInput() {
|
|
|
|
|
SDL_StartTextInput();
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
_flags |= Flag::TextInputActive;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::stopTextInput() {
|
|
|
|
|
SDL_StopTextInput();
|
|
|
|
|
#ifdef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
_flags &= ~Flag::TextInputActive;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::setTextInputRect(const Range2Di& rect) {
|
|
|
|
|
SDL_Rect r{rect.min().x(), rect.min().y(), rect.sizeX(), rect.sizeY()};
|
|
|
|
|
SDL_SetTextInputRect(&r);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::exitEvent(ExitEvent& event) {
|
|
|
|
|
event.setAccepted();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::tickEvent() {
|
|
|
|
|
/* If this got called, the tick event is not implemented by user and thus
|
|
|
|
|
we don't need to call it ever again */
|
|
|
|
|
_flags |= Flag::NoTickEvent;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::anyEvent(SDL_Event&) {
|
|
|
|
|
/* If this got called, the any event is not implemented by user and thus
|
|
|
|
|
we don't need to call it ever again */
|
|
|
|
|
_flags |= Flag::NoAnyEvent;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::viewportEvent(ViewportEvent& event) {
|
|
|
|
|
#ifdef MAGNUM_BUILD_DEPRECATED
|
|
|
|
|
CORRADE_IGNORE_DEPRECATED_PUSH
|
|
|
|
|
viewportEvent(
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
event.framebufferSize()
|
|
|
|
|
#else
|
|
|
|
|
event.windowSize()
|
|
|
|
|
#endif
|
|
|
|
|
);
|
|
|
|
|
CORRADE_IGNORE_DEPRECATED_POP
|
|
|
|
|
#else
|
|
|
|
|
static_cast<void>(event);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_BUILD_DEPRECATED
|
|
|
|
|
void Sdl2Application::viewportEvent(const Vector2i&) {}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
void Sdl2Application::keyPressEvent(KeyEvent&) {}
|
|
|
|
|
void Sdl2Application::keyReleaseEvent(KeyEvent&) {}
|
|
|
|
|
void Sdl2Application::mousePressEvent(MouseEvent&) {}
|
|
|
|
|
void Sdl2Application::mouseReleaseEvent(MouseEvent&) {}
|
|
|
|
|
void Sdl2Application::mouseMoveEvent(MouseMoveEvent&) {}
|
Platform: first-class MouseScrollEvent for SDL2 and NaCl application.
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
10 years ago
|
|
|
void Sdl2Application::mouseScrollEvent(MouseScrollEvent&) {}
|
|
|
|
|
void Sdl2Application::multiGestureEvent(MultiGestureEvent&) {}
|
|
|
|
|
void Sdl2Application::textInputEvent(TextInputEvent&) {}
|
|
|
|
|
void Sdl2Application::textEditingEvent(TextEditingEvent&) {}
|
|
|
|
|
|
|
|
|
|
#ifdef MAGNUM_TARGET_GL
|
|
|
|
|
Sdl2Application::GLConfiguration::GLConfiguration():
|
|
|
|
|
_colorBufferSize{8, 8, 8, 0}, _depthBufferSize{24}, _stencilBufferSize{0},
|
|
|
|
|
_sampleCount(0)
|
|
|
|
|
#ifndef CORRADE_TARGET_EMSCRIPTEN
|
|
|
|
|
, _version(GL::Version::None),
|
|
|
|
|
#ifndef MAGNUM_TARGET_GLES
|
|
|
|
|
_flags{Flag::ForwardCompatible},
|
|
|
|
|
#else
|
|
|
|
|
_flags{},
|
|
|
|
|
#endif
|
|
|
|
|
_srgbCapable{false}
|
|
|
|
|
#endif
|
|
|
|
|
{}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::GLConfiguration::~GLConfiguration() = default;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Configuration::Configuration():
|
|
|
|
|
#if !defined(CORRADE_TARGET_EMSCRIPTEN) && !defined(CORRADE_TARGET_IOS)
|
|
|
|
|
_title("Magnum SDL2 Application"),
|
|
|
|
|
#endif
|
|
|
|
|
#if !defined(CORRADE_TARGET_IOS) && !defined(CORRADE_TARGET_EMSCRIPTEN)
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
_size{800, 600},
|
|
|
|
|
#else
|
Platform: initial HiDPI support in SDL2 app on Linux and Emscripten.
This is quite complex, actually. The end goal is: when I request an
800x600 window, it should create a window of the same physical size as
an 800x600 window would have on a system default DPI. After that, the
actual window size (for events), framebuffer size and DPI scaling value
(to correctly scale the contents relative to window size) are
platform-dependent.
On macOS and iOS, the DPI scaling is done simply by having the
framebuffer twice the size while the window size (for events) remains
the same. Easy to support.
On Linux, a non-DPI-aware app is simply having a really tiny window. The
worst behavior of all systems. Next to that, SDL_GetDisplayDPI() returns
physical DPI, which is quite useless as the value is usually coming from
Xorg display autodetection and is usually just 96, unless one goes extra
lengths and supplies a correct value via an xorg.conf. The DE is using a
different, user-configurable value for scaling the visuals and this one
is available through a Xft.dpi property. To get it, we dlopen() self and
dlsym() X11 symbols to get this property. If this fails, it might mean
the app doesn't run on X11 (maybe Wayland, maybe something's just messed
up, who knows) and then we fall back to SDL_GetDisplayDPI(). Which is
usually very wrong, so this is also why I'm implementing two ways to
override this -- either via the app Configuration or via a command-line
/ environment variable.
On Emscripten / HTML5, all that's needed is querying device pixel ratio
and then requesting canvas size scaled by that. The event coordinates
are relative to this size, so there's not much more to handle. Physical
canvas size on the page is controlled via CSS, so no issues with stuff
being too big or too small apply -- in the worst case, things may
be blurry.
On Windows, the DPI scaling is something in-between -- if the app
presents itself as DPI-aware, window size is treated as real pixels (so
one gets really what is asked for, i.e. an 800x600 window on a system
with 240 DPI is maybe four centimeters wide). If not, the window is
upscaled (and blurried) by the compositor. In order to have correct
behavior, I first need to query if the app is DPI-aware and then either
scale the requested size or not (to avoid extra huge windows when the
app is not marked as DPI aware). That will be done in a later commit.
8 years ago
|
|
|
_size{}, /* SDL2 detects someting for us */
|
|
|
|
|
#endif
|
|
|
|
|
_dpiScalingPolicy{DpiScalingPolicy::Default} {}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::Configuration::~Configuration() = default;
|
|
|
|
|
|
|
|
|
|
std::string Sdl2Application::KeyEvent::keyName(const Key key) {
|
|
|
|
|
return SDL_GetKeyName(SDL_Keycode(key));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::string Sdl2Application::KeyEvent::keyName() const {
|
|
|
|
|
return keyName(_key);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::InputEvent::Modifiers Sdl2Application::MouseEvent::modifiers() {
|
|
|
|
|
if(_modifiersLoaded) return _modifiers;
|
|
|
|
|
_modifiersLoaded = true;
|
|
|
|
|
return _modifiers = fixedModifiers(Uint16(SDL_GetModState()));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Sdl2Application::InputEvent::Modifiers Sdl2Application::MouseMoveEvent::modifiers() {
|
|
|
|
|
if(_modifiersLoaded) return _modifiers;
|
|
|
|
|
_modifiersLoaded = true;
|
|
|
|
|
return _modifiers = fixedModifiers(Uint16(SDL_GetModState()));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Vector2i Sdl2Application::MouseScrollEvent::position() {
|
|
|
|
|
if(_positionLoaded) return _position;
|
|
|
|
|
_positionLoaded = true;
|
|
|
|
|
SDL_GetMouseState(&_position.x(), &_position.y());
|
|
|
|
|
return _position;
|
|
|
|
|
}
|
|
|
|
|
|
Platform: first-class MouseScrollEvent for SDL2 and NaCl application.
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
10 years ago
|
|
|
Sdl2Application::InputEvent::Modifiers Sdl2Application::MouseScrollEvent::modifiers() {
|
|
|
|
|
if(_modifiersLoaded) return _modifiers;
|
|
|
|
|
_modifiersLoaded = true;
|
|
|
|
|
return _modifiers = fixedModifiers(Uint16(SDL_GetModState()));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template class BasicScreen<Sdl2Application>;
|
|
|
|
|
template class BasicScreenedApplication<Sdl2Application>;
|
|
|
|
|
|
|
|
|
|
}}
|