A scrollbar button would be cast to a number-slider button, and values from
this memory used for scrollbar specific calculations. Looks like an error from
809499a3d0.
In practice the error wouldn't be visible, since the actually used value would
by chance be the intended value, from what I can tell. That's because
`uiButNumberSlider.step_size` and `uiButScrollBar.visual_height` have the same
memory offset within the button memory.
The OSL dependency is built with target sm_50 currently, which means
that LLVM defaults to generating PTX version 4.0. However, due to an
apparent bug in LLVM 20 it still uses instructions that were only
introduced in PTX version 6.0. As a result OptiX refuses to load the
shadeops PTX with an `OPTIX_ERROR_INVALID_INPUT` error.
To fix this, raise the PTX version generated by LLVM to 6.0 for both the
shadeops module (which previously used 4.0) and also any generated code
(which previously used 5.0) to be safe. PTX version 6.0 was introduced with
CUDA 9, so it has pretty long driver backwards compatibility still.
This commit contains fixes for the OSL, to fully fix the original report
a recompiled OSL libraries would need to land for the affected platforms.
Ref #147361
Pull Request: https://projects.blender.org/blender/blender/pulls/147620
Instead of reordering edges to be able to map them with hash sets, new
edges order (since 157e7e0351) is kept as-is in order to not
touch edge attributes. In early return in case of correct mesh this new
ordering was missed. This was found in file from #147694.
Pull Request: https://projects.blender.org/blender/blender/pulls/147872
Forgot that the Armature's bones list only contain root bones...
Fix the versioning code.
Also adding a 'recovery' extra versioning step for files that may have
already been opened and re-saved in Blender 5.0 (though this step is
not 100% handling all cases, in case some script or add-on already
created some system properties in a bone in 5.0, the existing user
properties from 4.5 and before won't be copied over anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/148125
Fix playhead snapping to seconds, when the frame rate is less than 0.5
FPS.
This makes it possible to snap to fractions of frames, to support setups
with multiple seconds per frame. Of course this only has any effect
(apart from not crashing) when sub-frames are enabled.
I've also added unit tests, and verified that the values are the same
from before this refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/148074
The issue here was that when an archive library ID is read from
blendfile (memfile undo buffer in that case), a new split main is
immediately created for it in `direct_link_library`, and the newly
read Library is assigned to its `Main::curlib` pointer.
However, in undo readfile code, when an old matching ID is found, the
new data is moved into that old address, to avoid modifying all other
unchanged ID using that re-read data-block.
For (archive) libraries, it means that their split main `curlib` pointer
also needs to be re-assigned to the re-used old address.
Pull Request: https://projects.blender.org/blender/blender/pulls/147744
Regression in [0] caused printing integers to crash.
While this function isn't widely used it could crash logging
key-map items.
Also add tests for IDP_reprN.
Ref !148109
[0]: 92cf9dd2f2
Before [0] this was read from the filepath, however some sequencer
operators only defined a `directory` & `files` and would attempt
to use a non-existent `filepath` property to detect if the path
was relative.
Resolve by making the directory relative as well as the filepath.
Ref !148106
[0]: 7d67113a8a
Opening "normal" windows (non-maximized) windows was hanging.
Blender was waiting for a "configure" event with a valid size,
which stopped being sent in GNOME-49.
Even though GNOME-49.1 will resolve the problem, according to the
GNOME developers Blender's use of Wayland was incorrect.
Resolve the issue with the following changes:
- Don't wait for the `xdg_toplevel` to be when creating new windows.
Instead, defer setting the window state using logic that was already
used for Vulkan.
- Set new window's pending size - used if no size is received
from LIBDECOR's "configure" callback.
- When the window is "configured" always set the window "state"
even if the size is not yet known.
Ref !148104
Improve mmap handling of IO errors on WIN32.
Make MMAP gracefully handle IO errors on Windows by replacing the
mapping with zeros using a vectored exception handler when an
EXCEPTION_IN_PAGE_ERROR is raised. This is similar to how such errors
are handled on non-Windows platforms.
On Windows, this is implemented by first creating a placeholder
allocation and then mapping the file into it. When an error occurs, the
exception handler unmaps the file, keeping the placeholder intact, and
creates an anonymous mapping into it, after which execution can
continue.
Since some required functions don't exist on older Windows versions,
the error handling will only work on Windows 10, version 1803 or newer.
Ref !139739
With #144591 it was not my intent to increase the width of the right-
side corner action zones when visible "Corner Handles" are enabled. It
is only the left side that gains the icon so making the right side
wider only interferes with other content. This PR just fixes this by
defining different widths for right versus left zones.
Pull Request: https://projects.blender.org/blender/blender/pulls/148076
While uncommon, brush initialization does happen in some addon
workflows. Prior changes to use custom pressure curves in more places
did not initialize the `CurveMapping` struct correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/147840
Remove support in the compositor for the following nodes:
- Combine Bundle
- Separate Bundle
- Closure Input
- Closure Output
- Evaluate Closure
- Repeat Input
- Repeat Output
Pull Request: https://projects.blender.org/blender/blender/pulls/147998
This commit fixes an issue where WM cursor grabbing, when used
in "hidden" mode (`GHOST_kGrabHide`) would unexpectedly not prevent the
cursor from escaping the Blender window and revealing itself when
hovering over macOS desktop elements like the application Dock.
Looking at the original issue in past Blender versions, testing with the
Walk Navigation operator, this used to work in Blender 3.2, and broke
in Blender 3.3. Bisecting leads to commit 4c4e8cc926 (Fix T99021:
Walk-mode doesn't work in Wayland), which switched the Walk Navigation
mouse warping method from custom `WM_cursor_warp` logic to using
`WM_cursor_grab_{enable/disable}`.
Then, looking at the WM_cursor_grab Cocoa implementation, more
especially at the `GHOST_kGrabHide` case in `handleMouseEvent`, a
comment ("Cursor hidden grab operation : no cursor move") suggests that
hiding the cursor would previously prevent it from moving (possibly in
earlier macOS versions?).
This fix, the simplest I could come up with other than implementing
simple window warping for the `GHOST_kGrabHide` case (similar to what's
done on Windows, see #113066) is to use
`CGAssociateMouseAndMouseCursorPosition` to disable cursor movements
for the duration of the hidden grab, effectively restoring the original
behavior indicated in the comment.
Pull Request: https://projects.blender.org/blender/blender/pulls/148007
Currently, sometimes shader code generation fails because the code of top-level
nodes is interleaved with the code of a repeat zone. See #147747 for more
details.
Previously, the code-generation order was just the standard toposort of the node
tree, but it does not guarantee that all nodes in a zone are next to each other.
Also, it can't easily, because the zone detection itself depends on the
toposort. This patch implements another sorting step on top of the default
toposort. It packs nodes in zones together without changing the validity of the
toposort.
This is an alternative to #147999.
Pull Request: https://projects.blender.org/blender/blender/pulls/148005
The inferencing algorithm does not work reliably when the tree has cycles. So
return early and assume everything is used. The user is expected to fix the bad
link as soon as possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/148009
This makes it so that the Pen Tool will return the handle type back
to `Align` after letting go of `LeftCtrl`
This effects Grease Pencil and Curves objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/147943
Quick tooltips immediately show a word or two and then shows more
detailed information after a pause. It is possible to have these two
things shows at differing positions (vertically or horizontally) and
therefore jiggle. Some padding code uses the width and height and half
of a padding amount, which can result in differing values if the first
width or height is an odd amount but the second is even, or vice versa.
This happens quite infrequently and depends on the user scale. This PR
just replaces one line that does the padding in a way that results in
consistent values.
Pull Request: https://projects.blender.org/blender/blender/pulls/148019
The cause was a missed case from #130440 where
`use_nla_remapping = true` was being unconditionally passed to
`fcurve_to_keylist()` rather than determining the value with
`ANIM_nla_mapping_allowed()` as it should have been.
The fix is simply to use `ANIM_nla_mapping_allowed()` instead of
unconditionally passing `true`.
This PR also changes an outdated comment to properly explain why `adt`
was null in the first place (which is precisely to catch bugs like
this).
Pull Request: https://projects.blender.org/blender/blender/pulls/147957
Currently, the scene strip preview uses the existing dependency
graph built for that scene. This was not a big issue before
the sequencer scene was introduced, because the user would have
to create two main Blender windows to run into problems.
Now with the sequencer scene, it's possible to look at the scene
of a scene strip within the same window.
When the user is editing the scene (e.g. moving an animated object)
any open sequencer preview will cause the edits to be flushed.
This can e.g. result in visual jumping of animated objects, and more.
This PR attempts to fix the issue in a straightforward way: Use
a separate dependency graph for rendering the sequencer preview.
While this fixes the immediate issues, there are some consequences:
* The memory usage of the scene dependency graph _can_ roughly
double (since there are now likely two instances of the same
dependency graph). Because of implicit sharing, unmodified data
will not be copied. But for example modifiers on meshes would
currently create two copies of the evaluated data in the two
dependency graphs.
* Creating the dependency graph can be costly, which will cause the
first frame that the scene has to render to be slower.
Note: The current code changes some properties of the original scene
like the frame, subframe etc. before rendering and then restores
the original state. In theory, this part of the code can be removed,
but may be a bit too risky for just a fix. This should be improved
at a later stage.
Also resolves#146769, #139501.
Pull Request: https://projects.blender.org/blender/blender/pulls/147457
Partial revert of c03fdf5d9d, going back to previous versions of the
icons for hide_on (closed eye), restrict_select_on (unfilled mouse
cursor), and the combined versions (vis_sel_xx). These changes are a
bit too contentious to be added so late in the release. Note this
leaves in the changes to the lock icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/147836
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
