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
Sequencer preview area drawing, when displaying float (EXR/HDR) final
image using GPU based display transform, was converting input float32
data to float16 data for the GPU texture, and the GPU was displaying
that float16 texture.
However this texture is displayed for just one frame, and the cost of
doing the conversion was pretty high. Just send incoming float32
data to the GPU instead.
Playback of EXR sequence at 2048x858 resolution, on
Ryzen 5950X / RTX 3080Ti: 28fps -> 70fps (time to do just the GL
texture upload: 28ms->3ms)
Pull Request: https://projects.blender.org/blender/blender/pulls/128829
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
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
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
Remove the box select tool from the timeline to simplify selection
logic, avoid confusion for users, and make maintaining the code
easier in the future. It also brings the selection system closer
to other industry-standard NLEs.
It also fixes an issue caused by d2091b4b1.
More details in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/128051
Previous change in there (d0cf4a4a8b, in 4.3 only) reverted
retiming keys to have one draw call per strip again. Which gets fairly
expensive if many strips have retiming keys.
However! All the strips are already drawn in two parts: all the regular
strips first, and then all the strips that are being "dragged over"
the other strips. So we can totally draw retiming keys for the whole
batch of strips at once, and it will just work out fine.
Viewing whole Sprite Fright Edit v135 timeline, on PC (Ryzen 5950X,
Win10/VS2022): draw_timeline_seq 7.4ms -> 5.8ms
(sequencer_retiming_keys_draw part 1.7ms -> 0.3ms)
Pull Request: https://projects.blender.org/blender/blender/pulls/128170
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
SEQ_render_is_muted is a fairly expensive, since it has to walk
a linked list of channels to find the one with the given index.
During timeline drawing, this was called for each strip multiple times.
Instead, get that value once per visible strip.
Viewing Sprite Fright Edit v135 whole timeline on Ryzen 5950X
(Win10/VS2022): timeline repaint 7.7ms -> 7.5ms
Pull Request: https://projects.blender.org/blender/blender/pulls/128057
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
Caused by incorrectly using mutable `ListBase` iterator, which caused
adding same strip to meta twice. This caused `next` and `prev` fields
to be set to same value resulting in infinite loop in next iterator.
Since multiple strips can be removed from list in one iteration, collect
these into `VectorSet` and move them in separate for loop.
Also do cache invalidation while strips are in original `seqbase`,
otherwise it can skip invalidation of strips downstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/127951
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
Finding which F-Curve (if any) drives the blend factor or volume of a strip is
fairly expensive (it has to search all the curves to find the one matching the
name). Speed that up by:
- Doing the f-curve lookups in parallel for all the visible strips,
- The found curve is stored in StripDrawContext, so this also avoids finding
the "volume" curve twice for the same strip (once for waveform, once for
fcurve overlay).
Viewing Sprite Fright Edit v135 whole timeline on Ryzen 5950X (Win10/VS2022):
timeline repaint 18.5ms -> 7.7ms
Pull Request: https://projects.blender.org/blender/blender/pulls/128015
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
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
Select handles of strip available below the cursor when
`selection.seq1/seq2` exists in `sequencer_box_select_invoke`.
Also fixed the condition in `sequencer_main_cursor` so the new
WM_CURSOR_HANDLE is visible.
Pull Request: https://projects.blender.org/blender/blender/pulls/126548
When playback framerate is too slow, then text was red and visible.
Otherwise it was black text on normally black background though, which
is not very useful.
Pull Request: https://projects.blender.org/blender/blender/pulls/127394
"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
VSE timeline, when many (hundreds/thousands) of thumbnails were visible, was
very slow to redraw. This PR makes them 3-10x faster to redraw, by stopping
doing things that are slow :) Part of #126087 thumbnail improvements task.
- No longer do mute semitransparency or corner rounding on the CPU, do it in
shader instead.
- Stop creating a separate GPU texture for each thumbnail, on every repaint,
and drawing each thumbnail as a separate draw call. Instead, put thumbnails
into a single texture atlas (using a simple shelf packing algorithm), and
draw them in batch, passing data via UBO. The atlas is still re-created every
frame, but that does not seem to be a performance issue. Thumbnails are
cropped horizontally based on how much of their parts are visible (e.g. a
narrow strip on screen), so realistically the atlas size is kinda
proportional to screen size, and ends up being just several megabytes of data
transfer between CPU -> GPU each frame.
On this Sprite Fright edit timeline view (612 visible thumbnails), time taken
to repaint the timeline window:
- Mac (M1 Max, Metal): 68.1ms -> 4.7ms
- Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 23.7ms -> 6.8ms
This also fixes a visual issue with thumbnails, where when strips are very
tall, the "rounded corners" that were poked right into the thumbnail bitmap
on the CPU were showing up due to actual bitmap being scaled up a lot.
Pull Request: https://projects.blender.org/blender/blender/pulls/126972
Implementing part of design outlined in #126087.
- VSE thumbnail cache has a new implementation, hopefully simpler
and easier to understand.
- Instead of cache key being a VSE strip, frame index, plus
complicated logic for cache items linking etc.,
- The cache is keyed by media file path (if multiple strips
use the same input file, they will share cache entries), frame
index within media file, and any extra data (e.g. steam index
for multi-steam videos)
- Much reduced cache flickering and strange/weird thumbnail choices.
- Likewise, thumbnails no longer disappear-and-reload on operations
like Undo, dragging new video strip into timeline, or F12 render.
- Thumbnails now load faster.
- Images use dedicated/faster thumbnail loading routines when a
format can do that (e.g. JPG and EXR can).
- Movies reuse ffmpeg decoding context for neighboring strips
that use the same file (as often happens when cutting footage)
- Thumbnail requests are processed on several threads now too.
Images and more detail in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126405
If the Timeline is sized too short to show any of the scrubbing area,
then the scrollbars obscure the time line and current frame marker.
This PR hides the scrollbars in this case. Also for similar cases with
Dope Sheet, Graph Editor, and the embedded Graph Editor/DopeSheet in
Movie Clip Editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/126806
Current default tool is "sample" which is a bit odd, and coupled with
the fact that the toolbar is hidden by default, this can be confusing
to new users, leading them to believe tweak/select tools are not
supported for the VSE preview.
This change:
- Sets "box select" as the default tool for the Preview
- Makes both Preview and Timeline toolbars shown by default
Pull Request: https://projects.blender.org/blender/blender/pulls/126336
Adds the ability to connect and disconnect strips in the VSE.
- Connected strips have an icon indicating their status, and attempting
to select one connected strip selects all other connected strips in
that chain.
- If the user attempts to connect a strip that is already connected to
other strips, that strip will disconnect itself from others before
connecting to new strips.
- Preview selection also works in bulk if multiple video strips are
connected together in the timeline.
- When adding new strips from the Add menu or the File Browser, strips
from the same file are connected by default. There's an option to
turn this off in Editing > Video Sequencer user preferences.
- It is possible to individually tweak strips/handles and ignore
connections with Alt+Click.
- This shortcut overrides the old keymap item for "Linked Handle"
selection. The property still exists if people want to use that
shortcut for its old purpose.
- To make sure that connections remain valid even after duplication,
I've added a condition to `seq_new_fix_links_recursive` that also
updates connections using the `seq->tmp` var. (A note -- I've updated
the comment for this field in `DNA_sequence_types.h` because the var
is only used for duplication now. It was once present in
`select_more_less_seq__internal` to be used for linked selection but
is gone now).
- There are also functions to cut one-way links and make sure that
all strips are bidirectionally connected after duplicating.
Pull Request: https://projects.blender.org/blender/blender/pulls/124333
SEQ_transform_sequence_can_be_translated, SEQ_transform_single_image_check,
SEQ_can_use_proxy can all trivially take const Sequence argument.
Made SEQ_give_frame_index take const Sequence too, by removing the
"modify seq strobe to be at least 1.0" code. The strobe itself is only
ever used inside the same function, and is already guarded by
"is strobe > 1.0" check.
Original code seems to be coming all the way from 2009 with
commit message "2.5. 12k lines of sequencer back!" (03fc5696dc).
Pull Request: https://projects.blender.org/blender/blender/pulls/126021
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
Retiming selection was way more complicated than it needed to be, with
lots of duplicate code between `sequencer_select_exec` and
`sequencer_retiming_key_select_exec` and logic scattered all over the
place.
This patch standardizes retiming selection so that all of its logic is
performed first. If it turns out that the cursor is not able to select
any keys, it continues with strip selection. This decreases linecount
and makes everything clearer.
There should be no regressions user-side, but this patch does fix a
couple bugs and makes retiming selection more robust:
- Prior to this patch, if no retiming keys were selected, attempting to
toggle any key with the tweak tool would select and deselect the key
immediately.
- Prior to this patch, retiming keys would still show if overlays were
turned off, but "retiming display" was turned on.
This patch also renames/changes some functions to make them clearer:
- `retiming_keys_are_visible` -> `retiming_keys_can_be_displayed`, since
having retiming keys on in the overlays does not guarantee that they
are visible in any strips currently. Note that I've altered this
function slightly too, this fixes the second bug mentioned above.
- `try_to_realize_virtual_keys` -> `try_to_realize_fake_keys`, to make
naming more consistent with existing functions.
- Fix typo in `retiming_mousover_key_get`
- Remove `use_retiming_mode` helper function since new code doesn't need
it -- was confusingly named anyways
- Add `key` and `key_owner` arguments to
`sequencer_retiming_key_select_exec` and
`sequencer_retiming_select_linked_time` to avoid having to recalculate
the key at cursor position over and over again
Pull Request: https://projects.blender.org/blender/blender/pulls/125468
VSE timeline widget drawing is done in "timeline space" (x: frames,
y: channels), but that can have precision issues at large frames,
when "pixel size features" (outlines, borders) need to get evaluated
inside a shader.
This can lead to inconsistent border sizes between neighboring strips,
e.g. sometimes it would be 2 pixels, but sometiems 3 pixels. I've seen
this mostly happen when frames get into 100'000+ range.
To address this, switch timeline widget drawing to be in window pixel
space. This avoids the issue since coordinates to draw the strip
widgets become "up to several thousand" range, not arbitrarily large.
Pull Request: https://projects.blender.org/blender/blender/pulls/125220
When 7afcfe1 removed the use of `startdisp` and `enddisp` for everything
but effect strips, not all of these variables were replaced in
`select_linked_time`, breaking the option. This option is used for the
select operator with the ctrl modifier in both LCS and RCS default
keymaps.
This patch fixes the bug, and also cleans up the old C code in the
function, replacing it with more robust logic.
- The new logic allows for the "linked time" option to be combined with
the "toggle" option -- old logic only propagated deselects if both
left and right handles were aligned.
- New logic makes sure that a selection is only propagated along the
side that you click by adding the selection handle as an argument.
(Before, you could align two strips on the left side only, "regular" select the
left handle of the top one, then "linked time" select the right
handle, and it would erroneously propagate the left handle selection
too).
This patch also fixes a bug where "both handle" selection would not work
if the linked time option was set, by making sure that if `seq2` is set
in `StripSelection`, then `select_linked_time` is run once more.
Pull Request: https://projects.blender.org/blender/blender/pulls/125039
After ce9becae4c the "fake" initial retiming keys were not rendered
properly. Fix this by undoing the part of can_draw_retiming that
added check for SEQ_retiming_keys_count.
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
With 2.7x keymap, clicking on selected strips does not de-select others.
Seems to be caused by leftover code, when some selection functionality
was moved to `SEQUENCER_OT_select_handle`
Pull Request: https://projects.blender.org/blender/blender/pulls/124779
To account for rounded corners, the meta/scene strip contents were
drawn with a horizontal margin on both strip sides. However this is
confusing and misleading, since it can look like the contents have
a frame gap between content start and parent strip start.
Instead, add vertical margins which do not have a possibility of
confusion with frame gaps.
Pull Request: https://projects.blender.org/blender/blender/pulls/124965
Clang (at least on OSX) has optimization issues with the pointer
version, which seem to be 'fixed' by using references.
Note that using references here is not a bad thing anyway (none of these
pointers would ever be expected to be NULL).
Pull Request: https://projects.blender.org/blender/blender/pulls/124883
It would not execute the "Frame Selected" action if the viewport already
fully zoomed out on the y-axis. However we still need to center the
viewport around the selected strips x position.
