This one was a bit more tricky, because the file loading is
mixed with versioning code and because collections are
embedded into scenes.
All tests that passed before, still pass.
Corrects incorrect usages of the word 'loose' when 'lose' was required.
Differential Revision: https://developer.blender.org/D9243
Reviewed by Campbell Barton
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
This patch "modernizes" `DNA_struct_switch_endian` similar to
how I updated `DNA_struct_reconstruct` recently. Furthermore,
some special case handling have been moved to another place.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D9089
BLO_version_defaults_userpref_blend -> blo_do_versions_userdef
The name was misleading as it was declared along with
BLO_update_defaults_startup_blend making it seem these functions were
related.
In fact preference defaults don't need to be updated as is done for
startup.blend since an in-memory blend file isn't used.
Rename the function to match other versioning functions
called from readfile.c. Also add/update comments on these differences.
Now versioning UserDef is run in readfile.c,
as is done for other Blender data.
Previously versioning was mixed with other run-time initialization,
so it needed to be called later by the window manager.
readfile.c's versioning function was only used for 2 variables.
Move versioning into versioning_userdef.c so everything
is done in one function.
Note: DNA_struct_elem_find checks have been replaced with checks for
the next released version.
This is harmless, as only old preferences saved between releases can
have their values overwritten.
Note: userdef versioning should be called from `do_versions_userdef`,
this will be done separately.
`workspace_hook` of wmWindows store pointers for runtime data and to
data belonging to other IDs (workspace's layouts). That kind of pointers
should always be cleaned up on read, it allows for cleaner segfault
crash in case of mistakes in code updating/re-setting them, and avoids
potential security issue of accessing random memory address.
No behavioral change expected here.
Relying on pointer addresses across different data-blocks is extremely
not recommended (and should be strictly forbidden ideally), in
particular in direct_link step of blend file reading.
- It assumes a specific order in reading of data, which is not ensured
in future, and is in any case a very bad, non explicit, hidden
dependency on behaviors of other parts of the codebase.
- It is intrinsically unsafe (as in, it makes writing bad code and making
mistakes easy, see e.g. fix in rB84b3f6e049b35f9).
- It makes advanced handling of data-blocks harder (thinking about
partial undo code e.g., even though in this specific case it was not
an issue as we do not re-read neither windowmanagers nor worspaces
during undo).
New code uses windows' `winid` instead as 'anchor' to find again proper
workspace hook in windows at read time.
As a bonus, it will also cleanup the list of relations from any invalid
ones (afaict it was never done previously).
Differential Revision: https://developer.blender.org/D9073
- Rename `find_elem` to `elem_offset` (matching `elem_exists`).
- Remove unused `SDNA_StructMember` return argument.
- Return an offset instead of a pointer which was being converted
back into an offset by one caller,
in this case there was no way to tell the difference between
and element that doesn't exist and a struct member
at the start of the array.
Resolves UBSan warning raised in T81340.
It looks like this code was left over from tabbed panels in the
properties editor. It wasn't used anywhere except for in one line of
the horizontally-aligned panel code that was recently removed.
Differential Revision: https://developer.blender.org/D8651
Remove the attempt to update the active layout pointers of each window
from whithin `direct_link_workspace`.
This piece of code was a nonsense for at least to critical reasons:
* Do not, never, ever, access data from another datablock within the
direct_link_... functions. Just don't. Don't try to be smart.
* Since it was trying (and failing) to update the active layout of every
window for every workspace, it was effectively setting those
`act_layout` pointers to NULL (remapping can only ever happen once,
trying to remap and already remapped new pointer is bound to fail in
any case).
Luckily (and funnily), this piece of code was actually harmless, since
setting the active layout would be overridden/redone later, in
`lib_link_windowmanager`, when updating their `workspace_hook` in
`lib_link_workspace_instance_hook`.
Note that the similar horror with `WorkSpaceDataRelation->parent` (which
points at a window) is kept for now, because that one is needed. Hope to
refactor it soon though.
When loading large files that are more than a couple weeks old
(such that DNA has changed in that time), a significant amount of
time is spent in `DNA_struct_reconstruct`. This function takes a struct
in the old layout and creates a struct in the new layout from it.
This was slow because it was computing the diff between the struct
layouts every time a struct is updated. Now the steps for the struct
reconstruction is computed only once per struct. This information is
then used to actually reconstruct all structs that changed.
I measured about 10-20% speedup when loading Spring files.
E.g. `10.6s -> 8.7s` for `06_055_A.anim.blend` in BKE_blendfile_read`.
This percentage varies a lot based on the number of blocks that have
to be reconstructed and how much DNA has changed since they have
been written. In none of my tests was the new code slower than the
old code.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D8959
The data layout remains exactly the same..
This change just gives all the elements in `SDNA->structs` names,
making it more comfortable to work with the data.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D8926
Allows scripters to store additional information in the marker itself instead
of using work-around approach based on marker names and such.
Differential Revision: https://developer.blender.org/D8944
This patch tries to sanitize the types of our size parameters across our read
and write code, which is currently fairly inconsistent (using `int`, `uint`,
`size_t`...), by using `size_t` everywhere. Since in Blender file themselves
we can only store chunk of size `MAX_INT`, added some asserts to ensure that
as well.
See {T79561} for details.
Differential Revision: https://developer.blender.org/D8672
This adds a search bar to the properties editor. The full search for
every tab isn't included in this patch, but the interaction with
panels, searching behavior, UI, region level, and DNA changes are
included here.
The block-level search works by iterating over the block's button
groups and checking whether they match the search. If they do, they
are tagged with a flag, and the block's panel is tagged too. For
every update (text edit), the panel's expansion is set to whether
the panel has a result or not. The search also checks for matching
strings inside enums and in panel labels.
One complication to this that isn't immediately apparent is that
closed panel's subpanels have to be searched too. This adds some
complexity to the area-level panel layout code.
Possible Future Improvements:
- Use the new fuzzy search in BLI
- Reset panels to their expansion before the search started if
the user escape out of the text box.
- Open all child panels of a panel with expansion.
Differential Revision: https://developer.blender.org/D8856
During undo/redo read code is expected to clear the `OB_MODE_EDIT`
bitflag of `Object.mode`, for some reasons.
This was not done anymore for re-used Objects, we need to add a special
handling case for that too.
Should be backported to 2.90 and 2.83 (will probably not be straight
forward for the latter).
