When Blender is started in fullscreen mode from the command line,
or if the fullscreen state is saved in the startup file, all temporary windows
will also open in fullscreen mode. When closing the fullscreen File Browser,
Blender would either crash or parent window becomes black.
This does not happen if the Blender switches to full screen manually.
`NSWindowCollectionBehaviorFullScreenPrimary` should be set for windows that
can enter full-screen mode. Otherwise macOS will turn the wrong window into
full-screen.
Similar fix: rB4b39de677d20
Differential Revision: https://developer.blender.org/D8708
Reviewed by: Julian Eisel
Mistake in cb578ca104. Before that, the extension vector was static,
to make sure the extension name strings wouldn't get destructed when
leaving the function. I didn't think that was an issue and couldn't
recreate one, because until the previous commit we wouldn't actually
add any extensions to the vector on Windows (the system I tested
with).
Use C++17's `std::string_view` now, which avoids the string copies
`std::string` creates for itself and thus its destruction when leaving
the local scope.
The OpenXR debug extension was disabled on Windows as a workaround. This
was an old leftover from when there was only the Windows Mixed Reality
runtime on Windows. The debug extension didn't work for it and we didn't
have a way to disable it just for Windows Mixed Reality.
Now it seems to work though, so we remove the workaround. If specific
runtimes still have trouble with the extension, we can disable it
specifically for these runtimes now.
Windows only workaround. I'll have to investigate Linux separately.
Steam's OpenGL compatibility is still new and doesn't work for us yet
(neither does it for standard OpenXR examples from what I've heard and
seen myself). We can work around that by falling back to our DirectX
compatibility layer.
Note that this DirectX compatibility still doesn't work for some
systems, see T76082.
Implementation note: Since the graphics binding extensions have to be
enabled before we can find out which runtime is in use (e.g. SteamVR vs.
Oculus, etc), we can now enable multiple graphics binding extensions but
settle for a single one to use later.
Once the SteamVR OpenGL backend works, we can remove this workaround
again.
Fixes T78267.
* Avoid deep copy of vectors (technically more than a cleanup).
* Use `std::make_unique` for allocating unique pointers, rather than
manual `new`.
* Use `std::optional` for optional by-value return values, rather than
C-style `bool` to indicate success + return-argument.
* Use references rather than pointers for non-optional arguments.
* Avoid manual `new`/`delete`. Use `std::unique_ptr` for local scope
bound lifetime.
* Use C++ `nullptr` rather than C's `NULL`.
* Remove unnecessary friend declaration.
These changes are generally considered good practise and move us more to
a "modern C++" style. We can still go much further of course.
See https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.
We can't exactly follow what we do for macOS here. On Windows special
characters can be inserted with Ctrl+Alt. So make sure we expect UTF-8
characters when Alt is held.
Mistake in 87062d4d67.
On windows, spacebar would be passed as UTF-8 text input, despite the
control key being pressed. On macOS, there already was an explicit
exception for this (command key in this case), on Linux XInput already
handled this case for us.
Note that Alt should still allow text input, for special character
sequences.
Issue also happened in the Text Editor if a text data-block was set.
Latest SteamVR OpenXR updates brought OpenGL support, but only with sRGB
buffers. I think for DirectX it's the same now.
It's not a big issue for us to use sRGB buffers, so that's what I will
do for now. That way we shouldn't need hardcoded exceptions for specific
runtimes that don't transform linear buffers correctly.
Steam just released a SteamVR update with OpenXR Developer Preview
support:
https://steamcommunity.com/games/250820/announcements/detail/2396425843528787270.
Once SteamVR is set up for OpenXR (see link above), it works with
Blender "out of the box", thanks to OpenXR!
We have to apply the sRGB transform workaround for SteamVR though,
otherwise it renders way too dark. Done in the next commit.
Note that AMD users may still only see a pink screen, because the
OpenGL-DirectX compatibility fails. I will check on a fix again.
For SteamVR on Linux we may have to wait for until it supports OpenGL
rendering for OpenXR. Alternatively, we *could* add initial Vulkan
support at Ghost level and use Vulkan<->OpenGL interoperability
extensions, Monado uses these as well.
When closing the File Browser window after making it fullscreen, Blender would
either crash or all windows would disappear, with no obvious way to bring them
back.
The "fix" is to not allow fullscreen for File Browsers (or any future "dialog"
windows), but only maximizing. From what I can tell that's how secondary
windows are supposed to work on macOS. What we previously did seemed like
something macOS doesn't handle cleanly, and I didn't find a simple way to do so
on our side.
With the Oculus runtime, the VR session would freeze when taking off the HMD
and putting it back on. This was caused by the deletion of graphics resources
too early in the OpenXR state machine, at least for Oculus.
The resources will now only be freed once the session is actually destroyed.
Also fixes an issue where it wasn't possible to stop the session via the UI
when the HMD was taken off.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D7635
With the Oculus runtime, the VR session would freeze when taking off the HMD
and putting it back on. This was caused by the deletion of graphics resources
too early in the OpenXR state machine, at least for Oculus.
The resources will now only be freed once the session is actually destroyed.
Also fixes an issue where it wasn't possible to stop the session via the UI
when the HMD was taken off.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D7635
Got added in 1a30e52142 (and tweaked in follow-ups) but shouldn't be needed
anymore with the newer popup based quit dialog.
It prevents Blender from quitting properly in case macOS closed all Blender
windows. This may happen in some corner-cases unfortunately (e.g. T74101) which
would be nice to have addressed at some point. Until then, users shouldn't have
to force-kill Blender to shut it down if they run into this.
