Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
Cleanup (and make slightly faster as a side effect) the way VSE effects
do multi-threading. Previously (some of them) were using
IMB_processor_apply_threaded with C-like machinery (which internally
uses a task pool), switch that over to a helper apply_effect_op
(which internally uses a parallel for). Based on profiling, parallel
for is slightly more efficient (task pool takes a bit until all the
tasks are "pushed" into the pool). Note however that some VSE effects
were already doing parallel for internally; these are not affected.
VSE scene at 4K resolution, with four 4K resolution PNG images blended
over each other, time it takes to do render_strip_stack:
- Ryzen 5950X (Win/VS2022): 38.9ms -> 34.7ms
- Mac M4 Max: 21.9ms -> 19.8ms
Now that all VSE effects are internally threaded via parallel for,
there's no need for the init_execution and execute_slice machinery,
so remove all that.
You might also notice that half of "over drop" effect code is gone.
It was accidentally not doing anything whatsoever for the last 18 years
(since 2.42), and currently observed behavior matches documentation
and "internet knowledge", so let's accept it as correct.
Pull Request: https://projects.blender.org/blender/blender/pulls/132380
Part of #130975: split off overly large VSE effects.cc (almost 4000
lines) into separate source files. No behavior changes.
- Add / Subtract / Multiply all go into one source file,
- Blend Over / Blend Under / Over Drop / other blend modes all go
into one source file,
- Cross and Gamma Cross go into one source file,
- All others go into their own files.
Pull Request: https://projects.blender.org/blender/blender/pulls/132323
