TODO: docs
TODO: I don't like the extra flag in viewport event, should this be
separate?
TODO: resizing directly from inside the event handler on GLFW causes a
loop where the window switches between the DPIs several times and then
gets resized to something extremely wide at the end, how to prevent
this? Is that due to window borders being differently thick?
TODO: there's a GLFW_SCALE_TO_MONITOR that makes the resizing somehow
automagic but it's too automagic for my taste, and should be under app
control instead
TODO: SDL halts all event processing while the window is dragged,
meaning the window only gets resized *after* it jumps to the other
display, which is freaking bad
TODO: Windows supply a "desired window rectangle" in the WM_DPICHANGED
event and it should probably get used, how to hammer it out of GLFW?
Interesting is that GLFW actually calls this but it does nothing
unless GLFW_SCALE_TO_MONITOR is enabled as well. Huh?
TODO: I guess because of the different window border sizes, even under
SDL whers is no feedback loop going back and forth between two
monitors several times causes the window to not be sized as expected
anymore, being a bunch of pixels off (803x607 and such). Not good for
my OCD. Solutions? GLFW is doing some calculations in its
GLFW_SCALE_TO_MONITOR routine, maybe that could get used?
TODO: WM_DPICHANGED can be caught by enabling SDL_SYSWMEVENT that's
disabled by default. Should this one be propagated to anyEvent() as
well? It generates *a lot* of events, however not propagating it might
be limiting for the user :/
Turns out this seriously broke properites that should always hold, such
as that R*S = M for a R and S extracted out of M. Another way to fix
this would be flipping signs in the rotation() / rotationShear() / ...
queries as well, but that adds extra operations to both rotation() and
scaling() and at that point it's just better to do what was done the
whole decade before.
To ensure this doesn't happen again and doesn't cost me a whole day of
debugging in an end-user app (SceneGraph TRS transformations got broken
because those assume that rotation() and scaling() *do* combine back,
which is a reasonable thing to assume), the docs are extended to note
this and there's an explicit test for both negative scale and large
angle corner cases as well.
This reverts commit 9aa68715db.
If the application is constructed with delayed window creation, the
warning would be printed on each context creation attempt / call to
dpiScaling(const Configuration&), which is silly.