This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias
for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled.
Description copied from the patch:
```
/**
* blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API
* of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers
* like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one
* still has to use std::mutex for that case.
*
* The mutex provided by TBB has these properties:
* - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to
* lock the mutex at the same time.
* - In the contended case, it spins a couple of times but then blocks to avoid draining system
* resources by spinning for a long time.
* - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes
* it more feasible to have many smaller mutexes which can improve scalability of algorithms
* compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender.
* - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the
* mutex when there are always more than one threads that try to lock it. In the majority of
* cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not
* guaranteed to be fair either.
*/
```
The performance benchmark suggests that the impact is negilible in almost
all cases. The only benchmarks that show interesting behavior are the once
testing foreach zones in Geometry Nodes. These tests are explicitly testing
overhead, which I still have to reduce over time. So it's not unexpected that
changing the mutex has an impact there. What's interesting is that on macos the
performance improves a lot while on linux it gets worse. Since that overhead
should eventually be removed almost entirely, I don't really consider that
blocking.
Links:
* Documentation of different mutex flavors in TBB:
https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html
* Older implementation of a similar mutex by me:
https://archive.blender.org/developer/differential/0016/0016711/index.html
* Interesting read regarding how a mutex can be this small:
https://webkit.org/blog/6161/locking-in-webkit/
Pull Request: https://projects.blender.org/blender/blender/pulls/138370
Movieclip can output buffer with smaller resolution than scene
resolution, but this was not handled in `strip_raw_image_size_get()`.
Small downside of this change is, that if movieclip source file can not
be read, its width and height is initialized to `IMG_SIZE_FALLBACK`.
So this may be confusing to users, but this would be quite rare
scenario.
Pull Request: https://projects.blender.org/blender/blender/pulls/138352
This feature allows you to change postion of origin/pivot for images
without changing their position.
It is implemented as property of transform operator. It is activated
by pressing `Ctrl + .` shortcut.
Move Origin item was also added to transform menu.
Origin can be snapped to 3x3 grid on strip image. This represents
most usual anchor points.
Ref: #134251
Pull Request: https://projects.blender.org/blender/blender/pulls/134206
* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
Ref: #132179
Renames:
- `Editing.act_seq` -> `Editing.act_strip`
- `SequenceModifierData` -> `StripModifierData`
- Its member `mask_sequence` is now `mask_strip`.
- `MetaStack.parseq` -> `MetaStack.parent_strip`
- Remaining function names/parameters that were not dealt with in #132748
- Various references to `seq` or `sequence` throughout code and docs when
referring to a strip
Also moves `_get` to the end of the renamed function names where
applicable for standardization (unless "by" or "from" are used).
There should be no changes to current behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/138077
Caused by recent refactor of strip input querying in #136474.
This caused `Strip::seq1` to be set even if effect strip has no inputs.
Fix was applied to `vse::strip_effect_get_new_inputs`, so it is less
confusing during debugging, but also to `seq::add_effect_strip`, as
I think, that core function should never produce invalid strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/138016
Caused by checking if strip frame index falls into a range instead of
timeline frame. This was introduced in 6a39d79967 and was incorrect
solution to the issue.
Cache key had `timeline_frame` field, which was removed, because it is
not updated when strip moves. The value is now calculated from frame
index.
The issue was not very noticable especially when working with larger
strips, but the behavior was incorrect and confused me when working on
cache related features.
Pull Request: https://projects.blender.org/blender/blender/pulls/137583
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
This patch completely reworks the slip operator from the ground up,
reorganizing code to be simpler and adding more clarifying documentation.
Major Changes:
- Add modal keymap to the operator along with an interactive status bar.
- Show offset overlays to the left and right of strips whenever slipping.
- Add option to "clamp" slipped strips.
- Rework input to be accumulative, avoiding "jumps" when transitioning in/out
of precision mode.
Fixes:
- Properly draw header when initializing operator before any events have been
sent, and reorganize event flow so that all events have an immediate effect.
- Properly clamp subframe slips.
More information in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/137072
This showed: argument 1 range [18446744071562067968, 18446744073709551615]
exceeds maximum object size 9223372036854775807.
It seems to think signed integers might lead to this kind of overflow,
but it's unclear why these two cases are causing warnings specifically.
Refactor the code to sidestep it.
Caused by not checking against key array size. The issue was introduced
in ee9e4ead8d. It looks like mistake done during refactoring, because
the code was supposed to fix previous transition segment, not only the
next one.
The previously code attempted to reduce levels of indentation, but it
was less readable and error prone. Now it should be more obvious what
the intent is.
Pull Request: https://projects.blender.org/blender/blender/pulls/136743
Strip locking was meant to be used with strip transformation only. So
the check, whether strip is locked is removed from hide/unhide operator.
Further it was requested to lock sound strip subframe offset. Since this
is time related property, it was moved to time panel. This also
addresses request to make it more obvious, why the value can't be
changed.
The name of the property was clarified from "Offset" to
"Sound offset", because there are another 2 offsets in the panel.
Finally, when channel is locked, properties in side panel now reflects
this state. This is done by adding RNA get function for `Strip.lock`
property. Function `seq::transform_is_locked` is used instead of
checking `SEQ_LOCK` flag, because it also checks channel state. With
this setup, the lock property can't be disabled while channel is locked.
However strip lock flag will be unset, which can be prevented. (I am not sure which is better. Both are fine in my eyes.)
Pull Request: https://projects.blender.org/blender/blender/pulls/135831
The "slip strip contents" operator in the VSE now can move the strip
keyframes. There is a property to enable keyframe slipping.
The property is disabled by default, mainly because animation is
often used for fade in/out, which would be annoying if it moved with
content.
Pull Request: https://projects.blender.org/blender/blender/pulls/136386
Crashes were caused by setting `Strip::machine` above `MAX_CHANNELS`
value.
Instead of clamping this value at multiple places, setter function
`seq::strip_channel_set` was added that implements clamping.
This also allows for better handling of clamping if it was ever needed.
Function `strip_transform_handle_expand_to_fit` still sets machine value
directly and above `MAX_CHANNELS` as a hack. This could be avoided, but
it would require some refactoring.
Pull Request: https://projects.blender.org/blender/blender/pulls/136163
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135747
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
There's no point in having non-threaded image color space conversion functions.
So merge the threaded and non-threaded functions and clarify names while at it:
- IMB_colormanagement_transform & IMB_colormanagement_transform_threaded
-> IMB_colormanagement_transform_float
- IMB_colormanagement_transform_byte & IMB_colormanagement_transform_byte_threaded
-> IMB_colormanagement_transform_byte
- IMB_colormanagement_transform_from_byte & IMB_colormanagement_transform_from_byte_threaded
-> IMB_colormanagement_transform_byte_to_float
These places were doing single-threaded colorspace conversion previously, and
thus now are potentially faster:
- IMB_rect_from_float (used in many places)
- EXR image "save as render" saving (image_exr_from_scene_linear_to_output)
- Object baking (write_internal_bake_pixels, write_external_bake_pixels)
- General image saving, clipboard copy, movie preparation
(IMB_colormanagement_imbuf_for_write)
- Linear conversion when reading HDR images/movies
(colormanage_imbuf_make_linear)
- EXR multi-layer conversion (render_result_new_from_exr)
For one case I benchmarked, which is to render out a 2D stabilized 10 bit input
movie clip out of VSE, the total render time went from 49sec down to 44sec
(Ryzen 5950X), one of the single-threaded parts was the colorspace conversion
in the movieclip code.
Pull Request: https://projects.blender.org/blender/blender/pulls/135155
with #133413 the intent was that VSE Text strips would not use the
fallback font stack if using a custom (non-default) font. However this
determination was done by comparing the font id. This was very weak as
the id can vary quite a bit within the first few fonts. This PR instead
adds a BLF function (BLF_is_builtin) that uses BLF_DEFAULT font flag
instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135014
If a sequencer text strip is using a custom font (not the default one)
then don't use the fallback font. This adds a new font flag to disable
the use of fallback.
Pull Request: https://projects.blender.org/blender/blender/pulls/133510
Instead of passing the `scene`, pass a pointer to the `Editing` struct.
This is the struct that owns the `StripLookup` in its `runtime`
so there isn't a good reason to use the `scene` pointer here
anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/134743
This removes the `scene` parameter of
`SEQ_time_get_rounded_sound_offset` and
`SEQ_time_media_playback_rate_factor_get`.
Instead, we now pass the `frames_per_second` directly.
This is an attempt at getting less of the code to be
scene dependent.
Pull Request: https://projects.blender.org/blender/blender/pulls/134741
This main thread check was introduced in 4536a4c610. At the time OpenGL
only ever worked in the main thread, but that limitation was lifted in
Blender 2.80.
With this operator being converted to use the jobs system, it now needs
to work in non-main threads. Note that this code does not run in parallel
with main thread drawing anyway, because of WM_job_main_thread_lock_acquire
and draw manager locks. What changed is that we can now activate OpenGL
contexts on other threads.
Pull Request: https://projects.blender.org/blender/blender/pulls/134696
All 2D vectors related to image transform code were changed to float2.
Previously, it was decided, that 4x4 matrix should be used for 2D
affine transform, but this is changed to 3x3 now.
Texture painting code did rely on `IMB_transform` with 4x4 matrix.
To avoid large changes, I have added function
`BLI_rctf_transform_calc_m3_pivot_min`.
Main motivation is cleaner code - ease of use of c++ API, and avoiding
returning values by arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/133692
