- "Is this strip type an effect?" has been done by reserving 3rd bit
of the effect enum values to indicate that. That is a very strange
decision, so make that be done by strip_is_effect() function. The
enum values have to stay the same for backwards compat however.
- Both "strip type" and "strip blend mode" were sourced from the
same STRIP_TYPE_ enum, with only parts of the values meant for "type",
and other parts of values meant for "blend mode". That again is highly
confusing; split that off into two enums. Yes there's a handful of
values in them that overlap, but not the majority.
Pull Request: https://projects.blender.org/blender/blender/pulls/145746
* PROP_COLOR_GAMMA is sRGB, not display space
* Hex colors are always sRGB
* Image byte buffers are in byte_buffer.colorspace
Fixes for sequencer text, image painting, render stamp and tooltips.
The default display space is sRGB, so this change will not be noticed
in most files.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
- BLF font flags were an untyped enum; change to actual enum and
update usages from int to that.
- Move all BLF API enums to their own header, so that if something
needs just the enums they don't have to include whole BLF_api.hh
Pull Request: https://projects.blender.org/blender/blender/pulls/143692
Gaussian blur effect size is expressed in pixels (not ideal, but that is
what it is). It was not taking render output scale or preview proxy
size into account, resulting in much larger blur at lower render scales.
Pull Request: https://projects.blender.org/blender/blender/pulls/143627
- Some functions that took integer arguments for proxy size enums; make
them take said enums directly.
- Add get_render_scale_factor() that calculates effective render scale,
use that in places that did manual "use either scene render scale setting
or proxy size" calculation in 5 places.
- Replace previous double with float in proxy size scale factors; all
the factors are exactly representable as floats, and all the calling
places used them as floats too.
- In various VSE related DNA structs, indicate which enums they use
as comments,
- Add enum types for the enums that were untyped,
- Move Wipe effect enums to DNA header for clarity, since they are
serialized values,
- Reduce SeqRetimingKey size from 40 bytes to 32 bytes; there
was too much unnecessary padding.
- Rename some enums SEQUENCE_ -> STRIP_ where relevant.
- Rename wipe enums DO_MEOW_WIPE -> SEQ_WIPE_MEOW
Pull Request: https://projects.blender.org/blender/blender/pulls/143565
Quite a few flags in `Strip.flag` were used only at runtime; they were
temporarily set and then cleared thereafter. Move them to
`StripRuntime.flag` instead.
Most of the moves are trivial renames, with some old versioning code for
`SEQ_FLAG_DELETE` deleted. That code fixed a very uncommon edge-case bug
in 2.x which doesn't seem worthwhile to keep deprecated code around for.
Pull Request: https://projects.blender.org/blender/blender/pulls/142776
Previously, newly added Gaussian Blur effect did not blurring at all,
since blur sizes were set to zero. Make them default to 9 pixel size
blur, which is similar to the amount of blur the Glow effect does by
default.
Pull Request: https://projects.blender.org/blender/blender/pulls/142851
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
- 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
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
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
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
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 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
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
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
