With two or more monitors of different scales, Blender would fail to
start in some cases when it opened on a monitor at a size that wasn't
a multiple of the monitors scale.
This seemed only to cause problems with LIBDECOR however the buffer size
should always be a multiple of the buffer scale, so ensure its always
valid.
See #135764 for details (a closely related bug).
There are issues with our implementation.
- X11 can flip image incorrectly.
- VVL complains of incorrect usage.
Disabling the extension for now until it is more clear what is not
correct.
This size isn't used unless `has_size_logical` is true,
setting fallback values that aren't used is confusing especially since
output rotation isn't applied - unlike the actual logical size.
Rotated outputs caused a workaround for a bug in GNOME to fail.
Also check the native size since the `size_logical` would always
be set to match the `size_native`.
Check for both `CF_TEXT` and `CF_UNICODETEXT` in
`GHOST_DropTargetWin32::getGhostType` because, unlike for the clipboard,
Windows does not synthesize `CF_TEXT` from `CF_UNICODETEXT` and vice
versa for drag and drop operations. Since `getGhostData` already
supports `CF_UNICODETEXT`, this is all that's necessary to make it work.
I encountered this issue when trying to drag text from Notepad++ into
Blender's text editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138524
The GHOST_DisplayManager and its implementations are for the most part
unmaintained and almost completely unused in all backends. To clean
things up, and avoid any confusion about how displays are handled in
each respective GHOST backend, this PR completely removes the GHOST
Display Manager, and move the few remaining logic it still held directly
to the corresponding backends.
The backends that were modified (apart from removing the display manager
initialization call from their init) are:
- Win32: `GHOST_SystemWin32::getNumDisplays()` was calling
`m_displayManager->getNumDisplays`, the underlying system metric call
(`GetSystemMetrics(SM_CMONITORS)`) was substituted in place.
- SDL: `GHOST_SystemSDL::createWindow` was calling
`GHOST_DisplayManagerSDL::getCurrentDisplayModeSDL` which returned its
`m_mode` data member by reference. Since none of the
`GHOST_DisplayManagerSDL` member function that modified this data member
were ever called, the variable `memset` initialization call was
substituted in place from the `DisplayManagerSDL` constructor
Pull Request: https://projects.blender.org/blender/blender/pulls/138066
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
When grabbing & hiding cursor under Wayland visually restored the
cursor location but didn't generate a motion event to update the
`wmWindow::eventstate`. Further events that used the cursor location
used the hidden location unless the user moved the cursor beforehand.
It is more convenient for math reasons, for Blender to treat a pen tilt
toward the user as a positive angle. This PR just reverses all the
comments about the expected values. And also reverses the values from
WinTab, Windows Ink, and Wayland to match.
Pull Request: https://projects.blender.org/blender/blender/pulls/137636
This PR removes unused Win32 code that we've had for about 13 years,
hidden behind a define that we've never enabled. The intent of this
optional code was to allow showing Blender windows as transparent,
something that looked pretty cool back then. The main method used was
an API call of DwmEnableBlurBehindWindow, but this function has not
done anything since Windows 8 because styles and tastes have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137620
On the Windows platform we get an initial bright white flash during
startup, before we start drawing on our canvas. This PR changes that
initial color to a mid-grey that is much less noticeable. After this
initial fill is done we then clear the background brush so Windows will
not use it later and slow down resizing by adding extra WM_PAINT
messages and fills.
Pull Request: https://projects.blender.org/blender/blender/pulls/137488
Pen tilt values come into Blender through ghost platforms and device
drivers with inconsistent and ambiguous directions. This PR codifies
that we consider tilt-x positive values to be rightward, negative
values as leftward. Similarly tilt-y positive is away from the user,
negative is toward the user. Comments are updated to make this clear.
This fixes Windows Ink (currently always returning left and away). This
also reverses the Wayland tily-y values to match. We might still have
to consider a user preference to swap directions if we find differences
within a platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/137501
This patch adds initial cursor support for the blade tool, with bitmaps
for 16x16, 24x24, and 32x32 cursors.
Additional Changes:
- Locked strips now show a "stop" icon when hovered over.
- Previously, the frame to split was truncated when clicking in between frames.
Now, round to the closest frame.
- Previously, the blade operator was able to select padded strip handles
outside of strip bounds. This bug has been resolved, so that selection with
the blade tool can only happen via box-select passthrough.
Pull Request: https://projects.blender.org/blender/blender/pulls/136749
Remove logic to access LIBDECOR's underlying XDG window since it
required an "dummy-buffer" workaround which caused a crash with recent
drivers that require a DMA buffer.
This introduces a slight flicker on startup in some cases
see code-comments for details.
Ref: !136289
Some OpenXR platforms do not support OpenGL or Vulkan. To support these
platforms we use a bridge. Blender still renders in OpenGL/Vulkan, but
will copy the render result into a D3D11 swapchain.
OpenGL doesn this by importing the D3D11 swapchain into the OpenGL
context and perfor OpenGL calls to update the swapchain. However for
vulkan that could lead to construct 3 context for OpenXR
- Blender GPU Context
- OpenXR D3D Context
- New context that imports the Blender render result and the OpenXR
Swapchain image and copies them.
Due to Direct3D limitations importing into a vulkan context has known
issues (driver + extensions). Secondly we are not sure if we are running
on the same device as the OpenXR swapchain. The solution provided with
this PR is to only support CPU data transfers.
**SteamVR using d3d bridge**
SteamVR normally would use the Vulkan binding. But by changing the binding
priority in code you can make it select the D3D bridge.
<img width="1518" alt="Screenshot 2025-04-10 114534.png" src="attachments/f856bb2b-9ad5-4bb2-9cfd-a1412da9edd1">
It has been tested and validated to work using Mixed reality portal as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/137264
Current Windows on ARM GPUs don't support
extenral memory. External memory is required
for OpenXR. So most likely OpenXR will not work
on these devices.
Most (read all) OpenXR platforms that support
vulkan also require external memory. So might
just be that those platforms won't work at all
on these devices.
In any case when not supported, the GHOST
OpenXR platform will use CPU for data transfer.
This PR add support to use a win32 handle to perform share render
result with the OpenXR vulkan instance. This is only possible when
the GPU matches. Otherwise a CPU roundtrip will be performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137093
Includes win32 specific extensions definitions when including
`vk_common.hh`. Inside `gpu_context.cc` vulkan needs to be
included before opengl, otherwise windows 10 builders will
report a warning.
```
[6421/7520] Building CXX object source\blender\gpu\CMakeFiles\bf_gpu.dir\intern\gpu_context.cc.obj
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\minwindef.h(130): warning C4005: 'APIENTRY': macro redefinition
C:\Users\blender\git\blender-vexp\blender.git\lib\windows_x64\epoxy\include\epoxy/gl.h(59): note: see previous definition of 'APIENTRY'
```
Pull Request: https://projects.blender.org/blender/blender/pulls/137134
In the OpenXR/Vulkan specs it is mentioned that the swapchain layout
should be set to optimal color attachment. This wasn't the case and
could lead to validation errors.
Also fixes a memory size validation error. Not concerning as it was
abount already backed memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/137143
This only worked for Ubuntu's discontinued Unity desktop.
Even though `libunity.so` can be used outside of Unity,
it's no longer actively developed.
Ref: !137128
When using SteamVR without starting SteamVR, the physical device cannot
be found. This isn't reported to the user nicely. This change will
tell the user why OpenXR couldn't be started.
Note that the physical device can be created when SteamVR has already
launched. OpenGL will start SteamVR automatically, but seems Vulkan
isn't able to do that.
Remove full-screen support from GHOST API's.
Note that this only had back-end implements for X11 and WIN32.
This was last used for the Game Engine to run games full-screen,
removing as it's unused and it doesn't seem likely to be used in the
future.
This doesn't impact making Blender full-screen from the window menu
which uses a window decoration setting.
Ref: !137050
Track the (per-thread) active `GHOST_Context`.
This is required to restore the active context after creating a new one
if the current context is unknown.
(Required for creating GPU contexts in the GPU module without depending
on the WM module)
Pull Request: https://projects.blender.org/blender/blender/pulls/136992
Current implementation uses a CPU roundtrip to transfer render result
to the Xr Swapchain. This PR adds support for sharing the render result
on Linux systems by using file descriptors.
To extend this solution to win32 or dx handles can be done by extending
the data transfer modes, register the correct extensions. When not
using the same GPU between Blender and OpenXR the CPU roundtrip
will still be used.
Solution has been validated with monado simulator and seems to be as
fast as OpenGL.
Performance can be improved by using GPU based synchronization.
Current API is limited as we cannot chain the different renders and
swapchains.
Pull Request: https://projects.blender.org/blender/blender/pulls/136933
Improve the number of images that are requested in the swapchain. For
mailbox presentation mode we select tripple buffering. For V-Sync
presentation mode we select double buffering.
In future we might want to make the presentation mode and swapchain
images dynamic based on the actual action that the user is performing.
When doing action that benefit from low latency (paint cursor) we should
select mailbox, otherwise we can use fifo to reduce CPU/GPU usage and
safe some energy usage along the way. See #136923 for design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/136922
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
