Caused by 2 issues:
- Incorrect logic when checking if added key matches last key
- FPS mismatch not compensated in `SEQ_retiming_key_speed_set()`
Also `seq_retiming_evaluate()` output was not clamped to 0-1 range. This
was not causing issues in sample .blend file, but output should be
clamped.
Pull Request: https://projects.blender.org/blender/blender/pulls/129838
This extends the `Vector` API to support transfering ownership of a memory
buffer to and from a `Vector`. This reduces the need for unnecessary copies in
some cases which converting between data-structures. A new
`VectorSet::extract_vector` method is added that takes O(1) time. Previously,
this was only possible in O(n) time by copying the entire array.
The `Vector::release` method can be used to e.g. build a vector with the C++
container, but then extract it for use in DNA data.
Pull Request: https://projects.blender.org/blender/blender/pulls/129736
There were lot of places, where timeline frame was incorrectly
mapped to frame index.
For deleting transitions, internal function `seq_retiming_add_key`
was added. It can work in frame index domain directly. This is to avoid
adding more complexity, since key positions are stored and re-created
later. Going through index to frame and back to index would introduce
float precision errors.
Pull Request: https://projects.blender.org/blender/blender/pulls/129305
init_gaussian_blur_effect was allocating memory for sizeof(WipeVars)
instead of sizeof(GaussianBlurVars). Not a problem today since WipeVars
is slightly larger, but this is an accident waiting to happen.
This patch fixes broken connections and effect strips which would arise
in some cases when trying to split connected strips with effects.
This happened in case an effect strip was being split -- first, its
effect chain would be added to a VectorSet of seqs, but then, only the
connected strips of the original seq (in this case the effect strip)
would be added to the VectorSet. Fix by iterating over the entire list
and adding connected strips.
Additionally:
- Add a final SEQ_iterator_set_expand() for SEQ_query_effect_chain() in
case these connected strips had effects themselves.
- Move the seq_edit_split_operation_permitted() check after the entire
chain is evaluated to avoid bugs w/ locked strips being editable
before.
Pull Request: https://projects.blender.org/blender/blender/pulls/128670
Building proxies for images was always saving them as JPG files.
However when input images are floating point (e.g. EXR files), this
loses both range and precision, making the resulting proxies
not really be useful for anything where you'd be using EXR files.
Change this to save float image proxies as EXR instead (FP16 data,
lossy DWAA compression). In my quick tests this does result in about
3x-4x larger proxy file size compared to JPG, however at 50% DWAA
quality that is still 10-30x smaller than original EXRs would be.
Changed proxy image loading to explicitly tell to load metadata. JPGs
were always loading it anyway, but EXRs only load when instructed to
do so.
Pull Request: https://projects.blender.org/blender/blender/pulls/128835
Tmp field was still used in strip duplication. This was a source of bugs
previously. Now it uses `Map` of new to old strips to fix strip
relations. The field is removed from DNA struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/128402
IMB_scale modifies the input image. But some places in code needed to keep
original input intact, so what they did was a sequence of IMB_dupImBuf+IMB_scale
Add IMB_scale_into_new function and use that in several obvious places:
- movieclip_build_proxy_ibuf
- icon_copy_rect
- seq_proxy_build_frame
Rebuilding proxies for VSE image sequences with 94 4K resolution EXR images
(on Ryzen 5950X/Win10/VS2022): 13.4 -> 10.3 seconds.
Pull Request: https://projects.blender.org/blender/blender/pulls/128752
This is a follow-up to #128363, and fixes up the remaining areas of
the sequencer's code that didn't yet account for slotted actions:
1. Moving strips failed to move their animation with them.
2. Duplicating strips failed to duplicate their animation with them.
3. Deleting strips didn't delete their animation channels with them.
This also takes the opportunity to add depsgraph tagging and
notifiers that were already missing in the pre-slotted-actions
code, for the strip delete and strip paste operators. The absence
of these was making the UI not update and was also causing stale
animation data to get evaluated.
Pull Request: https://projects.blender.org/blender/blender/pulls/128440
Previously, alignment did exist, but it only changed whole text block
position in relation to a fixed point. This was later renamed to "Anchor".
Now it correctly aligns each line of text. Alignment works with newline
character and word wrapping.
Currently newline characters can't be entered directly, but this should
be resolved soon.
To keep existing anchoring feature, new DNA fields are added and
values from old alignment are copied there.
This PR is part of bigger change [1], and originally I expected to
implement this feature at later stage. But the design called for drawing
text character by character, which would mean, that I would have to
rewrite text alignment anyway.
To render the text, a struct is built, where position and width of each
character is stored. In addition, width of each line is stored. This allows
to implement proper text alignment feature, instead of existing
anchoring. Text is then drawn character by character in a loop.
There are some small differences in text rendering, since this is only
approximation of how BLF library draws glyphs, but it is very close.
For text bounbox, `BLF_boundbox()` is used on per line basis,
because some fonts do not use their full height and this information
is not available on VSE side.
[1] https://projects.blender.org/blender/blender/issues/126547
Pull Request: https://projects.blender.org/blender/blender/pulls/126660
Before this, copy-pasting sequencer strips with animation on them would
fail to copy-paste their animation along with them if they were animated
by a slotted action. This fixes that.
There are three remaining known issues in the sequencer when used with
slotted actions that this PR does not fix, and will be addressed in a
follow-up PR:
1. Moving strips fails to move the animation of their fcurves with them,
which it should.
2. Duplicating strips (as distinct from copying followed by pasting)
fails to duplicate their animation with them.
3. Deleting a strip does not delete its animation channels with it.
Pull Request: https://projects.blender.org/blender/blender/pulls/128363
If conditions are not met for offscreen rendering, render job is used as
fallback. This can be skipped if there is possibility of race condition.
This was only considered for case where `context->for_render` was false,
since this indicates that call is invoked by the job itself.
If scene strip display is set to `OB_RENDER`, it needs to start the
render job. So variable `do_seq_gl` was renamed to `is_preview` and
reused in race avoidance connditon. This was done to convey clearer
meaning and match comments.
This change does make code less safe - race is avoided by UI not
allowing to run F12 render and opengl render at the same time. However,
I don't think, this could be easily resolved on VSE side without
suspending thread or being able to run multiple render jobs.
Pull Request: https://projects.blender.org/blender/blender/pulls/127926
+0.5 should be added to integer pixel coordinate (sampling at pixel
center). This is only really visible in very specific scenarios, but
is more correct.
When adding sound strips, it would in some cases be offset
from the desired start position.
This was because some sound files had a start time that was not 0
even if they didn't have any video file associated with them.
Only try to shift the sound strip around if it is added with a video
strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/127256
When I was learning VSE code, MAXSEQ constant (a preprocessor define!) was
confusing. It makes it sound like it is "max sequences", but it is actually
"max channels". So rename it to SEQ_MAX_CHANNELS and make it C++ constexpr int
instead of preprocessor macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/128024
Drawing the list of channels on the left side of VSE timeline was taking
surprisingly long time (3.5ms in Sprite Fright Edit v135 on Mac M1 Max).
This PR makes them draw in 0.4ms, i.e. 10x faster, by doing two things:
- Stop "search through the whole timeline" work whenever we need to know
which meta strip (if any) owns some VSE channel. Remember that info in
the "sequence lookup" that already holds data to speedup similar queries
(sequence by name, meta by sequence). I.e. this gains "channel owner by
channel" query hashtable.
- Stop alternating between "regular font glyph cache" and "svg icons glyph
cache" on each channel row, which incurs a draw call / UI batch flush.
Instead, draw all the lock/mute widgets first, then all the channel names.
While at it, simplify code related to sequence lookup:
- Use C++ mutex with lock_guard
- Use BLI Map instead of GHash
- Simplify SEQ_sequence_lookup_tag to just SEQ_sequence_lookup_invalidate
- Remove unused SEQ_get_meta_by_seqbase and SEQ_query_all_meta_strips_recursive
Pull Request: https://projects.blender.org/blender/blender/pulls/127913
VSE tonemap is 12-15 times faster.
1) multi-threaded image luminance calculation,
2) avoid calling into OpenColorIO per-pixel, instead do that in
larger batches,
3) for float images (which are primary target for tonemapping),
do not do "to linear space" conversion twice.
Applying tonemap on 4K resolution EXR image, on Ryzen 5950X (Win10/VS2022):
- R/D Photoreceptor mode: 405 -> 31 ms
- Rh Simple mode: 388 -> 23 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127467
To avoid unnecessary looping over listbase items the function
`BLI_listbase_count_at_most` was used however it resulting in an awkward
expression: `BLI_listbase_count_at_most(list, count + 1) == count`
replace this with `BLI_listbase_count_is_equal_to(list, count)`.
Do not try to kill thumbnail generation job when destroying the cache
(which happens as part of destroying the scene) -- all the code
paths that destroy a scene already cancel outstanding WM jobs. And WM
itself might be gone at that point, so accessing a stale pointer to it
can lead to a crash.
Instead, fix the problem of "refresh sequencer can cause a crash" by
not destroying the thumbnail cache, but merely clearing it in
sequencer_refresh_all_exec.
Pull Request: https://projects.blender.org/blender/blender/pulls/127485
"seq3" input for VSE effect strips has been there ever since
"initial revision" commit in 2002, with comment "pointers voor effecten"
even. But it has never been used, so remove all code that pretends
to do something with it.
Pull Request: https://projects.blender.org/blender/blender/pulls/127401
When doing average/min/max luminance calculations for tonemapping, ignore
pixels that are outside of the strip rectangle. Due to how VSE innards work,
when a strip is positioned to not cover the whole screen, "the rest" is filled
with transparent black. For tonemapping, this was dragging average calculated
luminance way down.
Images of the issue in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/127207
Image/movie strip controls color controls: "Saturation" and "Multiply" were
both single-threaded code. Multi-thread both of them. Timings to apply them
on a 4K resolution byte image, on Ryzen 5950X (Win10/VS2022):
- Saturation: 97ms -> 6.3ms
- Multiply: 11.5ms -> 1.1ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127409
SEQ_modifier_apply_stack is called from exactly one place, and it always
was throwing away the input image, and taking the newly produced image.
Which means, we can stop copying it. Just run the modifiers on the
input image.
In a test file that is HD (1080p) resolution, two EXR image sequences,
adjustment layer with Color Balance, and a text strip on top,
playback framerate (Ryzen 5950X, Win10/VS2022) goes 20.8 -> 22.1 fps
Pull Request: https://projects.blender.org/blender/blender/pulls/127346
When a strip with alpha-over blend mode (which is default) has an alpha
channel and is at the bottom of the whole stack, there's no point in
blending it with black color; the result will be identical.
So stop doing that. Also, whenever some other case happens at the bottom
of the stack (e.g. some other blend mode), create the fake "black input"
image at the needed color type (float or byte) and with the correct
color space already applied. Otherwise, especially for floats, VSE
spends much time converting this fake black input from byte to float,
and then converting it to sequencer color space.
Test case of two EXR files blended over each other, at 4K resolution,
on Ryzen 5950X (Win10/VS2022):
- whole sequencer_preview_region_draw 115ms -> 75ms
- seq_render_give_ibuf part: 64ms -> 24ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127310
