Regression caused by 9e4c26574a.
Add strip stack as a key to the final cache.
Use the pointer to the list of sequences, as it is the easiest one to
obtain in all places where it is needed. This is slightly different
from the code prior to the 9e4c26574a where strips.last() was used,
but it allows to use the same logic in the prefetch job.
Pull Request: https://projects.blender.org/blender/blender/pulls/141778
Blender expects float buffers to be in scene linear space, which was
violated bu the 1012bit movie reading code. While such image buffers
can be displayed correctly, performing operations in various areas
of Blender might lead to unexpected results.
The non-linear colorspace for ImBuf is expected to be "internal-only"
to a specific area, like VSE.
This is only done for Image and MovieClip data-blocks, sequencer still
reads movie files in their original colorspace as it helps performance and
sequencer can not be referenced from places where linear colorspace
for float buffer is really important.
Pull Request: https://projects.blender.org/blender/blender/pulls/141603
Make display channel part of the key for the final cache.
The prefetch uses display channel of 0, which is the default. It might
need to be adjusted, but it is unclear whether it was behaving different
prior to the 9e4c26574a.
Pull Request: https://projects.blender.org/blender/blender/pulls/141670
New sequence strip modifiers get a name that is to be translated if
translation of data is enabled. This used the default translation
context, but "Sequence" must be used because this is the context used
to extract the modifier names (`modifiersTypes` array in modifier.cc).
Reported by Ye Gui in #43295.
If render settings resolution scale had lowered resolution, cached
images from render image/animation session could "stay around"
and be incorrectly used in the VSE preview area. Two cases I found are
fixed here:
- Intra-frame cache was not flushed upon actual final resolution
change,
- "Source images" for effect/scene strips were not removed when
requested resolution no longer matches their rendered resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/141297
I18n: Translate a few messages
- Translate add-on types in the user preferences.
- Translate a report which uses formatting.
- Do not translate scene names in `sequencer.scene_strip_add` operator
UI.
- Do translate the type of new scene in
`sequencer.scene_strip_add_new` operator.
- Translate Half and Float image format color depth enum items.
- Translate Mix node header with non-color data types.
- Translate sequencer modifiers' names if data translation is enabled.
Most issues reported by Ye Gui in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/141145
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
Text strip had a fixed size buffer of 512 bytes to hold the displayed
text (this can be much fewer actual characters with non-English
languages). Switch to dynamically allocated buffer instead, which can
hold longer text.
In order to support forward/backward compatibility, TextVars continues
to hold the 512 byte buffer in memory. When writing out the .blend file,
dynamic text buffer is copied into the fixed one. If it is longer, the
text is truncated, so opening the .blend file in an older version
will contain the first 512 bytes of the longer text. When reading
existing files without the dynamic text buffer, it is created from the
static buffer. Conceptually this approach is similar to constraints
name length increase PR !137310.
The text strip editing code was switched to operate on the dynamic
buffer, resizing it as needed. seq::CharInfo internal struct was
switched to be more independent of the actual buffer address; now
each char entry just stores an index into the buffer instead of direct
pointer (side effect: makes the struct smaller as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/140733
Text strip along with other effect strips draws into buffer, which is
defined by common render size. However this makes selection, snapping
and other features not work correctly from user perspective.
There are 2 ways to remedy this:
- Draw text into buffer which size is defined by text boundbox
- Just draw the correct size boundbox and make UI use it correctly
This PR implements second option, as there are multiple difficulties
asociated with first option. Main problem is, that one would need to
calculate boundboxes for all individual text effects(blur, shadow, ...),
but many of these effects need to know the size of buffer we are trying
to calculate.
Big question here was: What the boundox should look like?
For selection it is best, if it encapsulates the text itself along with its
effects like shadow, blur or box. However for snapping and pivot range
it seems, that encapsulating only the text without any effects applied is
the best solution. This was discussed with UI module and we agreed,
that encapsulating only the text would provide better usability.
The implementation:
Most of the features are on "preview side", where all dimensions are
related to scene render size. Temporary `TextVarsRuntime` is created to
calculate apparent text strip image size. This allows boundbox of
correct size to be drawn.
However to draw boundbox and do transformations correctly, it is
necessary to remap origin point to the subset of image defined by the
boundbox. Since recalculated origin is relative, this function is used
for image transformation during rendering as well.
Main drawback of this method is, that boundbox and origin point
calculation may be needed from multiple places, and `TextVarsRuntime`
may be recalculated about 10x on redraw. `text_effect_calc_runtime`
function can be executed from ~5us for single character to 0.5ms with
512 characters with default font(not sure if that matters).
Drawing origin only during transformation would help with general UI
responsiveness. During playback, these overlays are not drawn, so
there should be no change in performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/140420
`seq_need_scale_to_render_size` returned true, when scaling was not
needed. The code that used this function worked correctly, so the logic
was inverted in both places.
We wouldn't clear the cache we disabled leading to end users needing to
trigger cache refreshes to eventually clear out the cache that they
disabled.
This also fixes a minor issue where the prefetch would try to prefetch
even if there were no caches enabled.
Sometimes we could get into scenarios where the prefetch would stop and
restart endlessly. Now we only stop the prefetch job when we don't want
to continue to prefetch anymore. Before we would exit when there is
currently no more prefetch work to do.
Before this change prefetching would not work correctly with only RAW
caches. The RAW caches wouldn't previously be emptied either if
switching them off while prefetching was turned on.
Now the prefetch will start prefetching from the start frame if it hits
the end frame and still have cache space to spare. This improves
playback when playing loops. It also makes it possible for end users to
define an area to pre-fetch by setting the preview range.
Start frame and especially channel picking algorithm was sub optimal. It
is much better to leave final strip placement decision up to the user
in a form of modal operation.
Move Strips property is added to strip add operators. When enabled,
strip is added to position of mouse cursor, strip overlap is allowed
and strip position then can be changed during modal seq_slide
operation, which is invoked automatically.
This property is saved and drag and drop operations do not change it,
thanks to store/restore hack facilitated by operator customdata.
If translation after strips are added is canceled, added strips are
removed.
Effects with inputs do not use this feature, as their placement is
restricted in X axis and 99% of time, it would be placed directly above
the input strip.
Since the strips are to be placed to mouse position after "modal"
filebrowser is closed, `eventstate->xy` of `wmWindow` is used to read
mouse cursor position in operator exec function.
The seq_slide operator is invoked using `WM_operator_name_call_ptr()`,
as macros or other schemes do not fit this use-case.
Ref: #136515
Pull Request: https://projects.blender.org/blender/blender/pulls/138382
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
After 9e4c26574a, `relations_invalidate_cache()` for sound strips
returns without doing anything, but VSE code relied on this function to
tag scene to update `ID_RECALC_SEQUENCER_STRIPS` which is mostly audio
related. Since the name of this enum value is not very descriptive,
clarifying comment was added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139991
This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
New VSE cache implementation (!137926) uses the same eviction
logic for the source image ("raw") cache as for the final frame cache --
remove the frames furthest away from the playhead.
However, source image cache keys are source media frames, not timeline
frames, so this was not working correctly when strips are not at
timeline start.
So, for each cached entry record the strip-start-relative timeline
frame that the entry was created at. This takes care of things like
retiming, reversed frames etc. And also makes the cached frames
visualization more correct in presence of frame reversal etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/139667
Use these terms over "Cross" and "Gamma Cross" in the UI/RNA
when referring to effect strips.
Keep it as "Cross" for blend modes for now (which is in and of itself
a bit of a weird naming. In the future, we should consider unifying
our blend mode types with compositor ones for consistency).
Pull Request: https://projects.blender.org/blender/blender/pulls/139606
- Previously, effects could be changed into types that take different
amount of inputs, e.g. from "add" to "glow", which led to undefined
and glitchy behavior (unreported bug). Fix by requiring same input count
for new effect.
- Previously, strip names were not updated when changing effect type,
which tended to be confusing. Now, if the default name was not changed,
update to the new effect type name.
- Remove "effect strip" menu from color and text strips. Although they
are effects internally, to a user, this is not clear, and providing the
option to modify effect inputs in these cases doesn't really make sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/139514
Previously there was no mechanism to invalidate scene strip cache, when
changes were made to scene that the strip renders. Because of this, the
cache had to be cleared manually, even for other strips.
Strip invalidation is performed from function
`ED_render_id_flush_update`.
Recalc flags like selection or frame change are ignored as they are
unlikely to influence the rendered image.
When some ID is changed, all scene strips using
`DEGEditorUpdateContext::scene` will be invalidated.
Limitations:
- Because frame change is ignored, changes to physics caches would not
invalidate VSE strips
- Only active scene will be invalidated this way. So if an object is
linked to 2 scenes, inactive scene cache would be invalid
- If animated object is moved, and there is VSE preview to be updated
Scene re-rendering in VSE would cause object to snap to its evaluated
position. This is because scene frame is changed by VSE. Reported in
#139501.
To refresh VSE preview after cache is invalidated, relatively big chunk
of code was copied from `view3d_main_region_listener` to VSE preview
listener. Cases that would not result in visual changes like selection
were excluded.
Fixes#113137.
Pull Request: https://projects.blender.org/blender/blender/pulls/138231
When strip is added, operator first finds "best" channel to place a
strip in, then adds new strip to that channel and finally does check if
the strip is overlapping other strips. If it does, it handles the
overlap.
To prevent adding strip to locked or muted channel, fix has to be done
at 2 places:
- `sequencer_generic_invoke_xy_guess_channel` which finds the "best"
channel
- `transform_seqbase_shuffle_ex` which handles overlap.
Further check for free channels was added to all strip add operators.
If there is no space above channel, that user selected, error is
displayed and operator is cancelled.
Note, that `transform_seqbase_shuffle_ex` is used only for resolving
overlaps where strip position in time must stay constant, so it moves
the strips in Y axis. This PR does not affect user selectable
`overlap_mode`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136016
Use a similar convention for struct member identifiers,
(the identifiers without surrounding spaces). This allows the values
to be scanned and validated.
This should make VSE code more readable and easier to understand from an
outside perspective.
The name was chosen to be `channel` rather than `channel_index` to keep
things short and concise -- it should be clear based on the context
whether we are talking about the strip's channel index (singular case,
`Strip::channel` or `SeqTimelineChannel::index`) vs. the channel list
(plural case, e.g. `Editing::channels`).
Pull Request: https://projects.blender.org/blender/blender/pulls/138919
This patch renames `seq1` and `seq2` to `input1` and `input2` in `Strip`
and `StripSelection` structs to consist with recent refactors in
#132179. It also renames other instances of `seq1` and `seq2` (e.g.
local variables) to `strip1` and `strip2` instead.
There is only one small breaking change to the Python API with
`strips.new_effect()` taking in the new names now. There should be
no other functional changes involved.
Pull Request: https://projects.blender.org/blender/blender/pulls/138296
Rework internals of how VSE caching is done. Primarily to make all the
caching logic more understandable from development point of view, but
also has several user visible implications (more details in the PR):
- Simpler and fewer caching UI options,
- Disk cache is gone (primary reason: proxies are kinda the same thing),
- VSE cache size set in preferences is actual size used for VSE caches
now (previously caching stopped as soon as whole Blender used that
much memory, even if some memory usage was not about VSE at all),
- Certain scenarios of cache invalidation are faster now.
Pull Request: https://projects.blender.org/blender/blender/pulls/137926
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
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
