On KDE, running "blender -w" (windowed with borders) created window
which was too big: the window contents matched the screen-size
causing the window decorations be outside the screen-bounds.
Un-maximizing the default startup file would also move window to the
same over-sized location.
Resolve by clamping the size of new windows to the requested bounds.
Scrolling the mouse wheel fast can generate multiple click-steps
which were ignored by window manager events.
This meant scrolling fast with a trackpad (with "Multi-touch gestures"
disabled) for e.g. would zoom less than the gesture made more slowly.
This macro makes it convenient to define a supported version range for
an interface.
Uncommenting USE_VERBOSE_OLD_IFACE_PRINT prints when newer versions
of an interface are supported by the compositor which Blender could
be updated to support.
This makes it more convenient to bump interface versions as they
become available so bumping multiple versions at once doesn't
cause unexpected changes in behavior as happened with #120587.
Resolves the issue reported in #120587, which occurred when bumping the
supported version of the seat API to 9.
Smooth scrolling values were set in without calling the discrete step
callback. Resolve by calculating discrete values from the:
wl_pointer_listener::axis_value120 handler.
The functional changes from this commit only apply once the version
of the seat API is increased - which isn't part of this commit.
This matches behavior on macOS as well as the property description.
On Wayland, smooth scrolling doesn't use the touchpad API,
so disabling multi-touch gestures doesn't change the behavior as it
does on macOS.
Resolve by converting vertical touch scrolling to mouse-wheel events.
Ensure that the MemHead and MemHeadAligned are such that memory
allocation followed with the head offset keeps the allocation
aligned to at least MEM_MIN_CPP_ALIGNMENT.
Pull Request: https://projects.blender.org/blender/blender/pulls/120582
The callback to set the relative direction wasn't running because
it required GHOST to request version 9 of the wl_seat_interface.
Natural touchpad events now work for KDE 6 and recent versions
of WLROOTS based compositors, GNOME 46 is uses wl_seat_interface
version 8 which still wont work.
MoltenVK original intent was to let developers work on a mac system developing
for the vulkan eco-system. MoltenVK doesn't support all the features that we
require and would require additional workarounds to be actually supported.
It is not expected that we will release Blender with MoltenVK for this reason.
But it still has value for shader developers to validate shaders on metal and
vulkan on a single platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/117940
This is a regression since fdc2962beb
The size of state can not be different between CPU and GPU.
This change replaces compile-time condition with a kernel feature
check, which solves the render regression on AMD Metal. It also
minimizes the state size on other GPUs when Light Tree is disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/120476
Ever since commit [1], `use_metalrt_by_default` will be True
if the GPU being used is not a M1 or M2 based system.
The intention of this was to enable MetalRT by default for
M3 and newer devices that have hardware for ray traversal.
However the side effect of this change was that all AMD GPUs would
have `use_metalrt_by_default` set to True. Which appears to be the
main culprit causing crashes on older AMD GPUs in #120126.
Since these GPUs don't support MetalRT.
This commit fixes this issue by only setting
`use_metalrt_by_default` to True if the GPU is not M1 or M2 based,
and the GPU is Apple Silicon based. Which equates to M3 or newer.
Which is the original intent of this code.
This resolves the issue where AMD GPUs were being told to use MetalRT
by default, when they shouldn't be.
[1] 322a2f7b12
Pull Request: https://projects.blender.org/blender/blender/pulls/120299
The issue was caused by the special code in Cycles which clears object
caches when it thinks they are not needed. We should not free caches of
grease pencils because it is needed later by a separate render engine.
Pull Request: https://projects.blender.org/blender/blender/pulls/120315
This is a regression in 4.1, caused by 36e603c430.
For unbiased MIS weight in light tree, we should use sd->N for
mis_origin_n, since sc->N is not available in NEE.
The change also makes it so we do not sample lights below sd->N even
when bump map correction is disabled. This diverges from the original
idea of giving full control to artists, but ensures the internal math
is happy.
Pull Request: https://projects.blender.org/blender/blender/pulls/120216
We call UpdateWindow very early in our window creation, before we get
an openGl surface and before our message queue is ready. This results
in WM_ACTIVATE, WM_SIZE, WM_MOVE, and WM_PAINT messages sent to us
at a time when GetMessageTime() returns zero. This makes our event
message times have a gap between the fourth and fifth messages, equal
to the time since system start. There is no downside to not calling
this at this time.
Pull Request: https://projects.blender.org/blender/blender/pulls/117965
fdc2962beb indirectly introduced a change
in inlining (light_tree_pdf started getting inlined) that led to a 5-10%
drop in performance for most scenes.
Dropping the noinline keyword for oneAPI device recovers it.
It however brings another performance regression to MNEE and Raytrace
kernels, that we'll look into separately.
While an empty string resolves to the default theme, it's not following
the API specification for wl_cursor_theme_load as it's written.
Checking on wayland internals this looks only to add an unnecessary
theme lookup on an empty string which falls back to the default.
Noticed when investigating #105895 although it seems unlikely
that this chagne would resolve the issue.
The Perlin noise algorithms suffer from precision issues when a coordinate
is greater than about 250000.
To fix this the Perlin noise texture is repeated every 100000 on each axis.
This causes discontinuities every 100000, however at such scales this
usually shouldn't be noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/119884
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
