Use multithreading, plus make the non-float / non-separate luma
calculations faster by avoiding byte->float->byte conversions
back and forth.
On a 4K resolution sequencer display, time taken to calculate the
waveform (Windows, Ryzen 5950X):
- regular images: 127.0ms -> 6.4ms
- regular images, separate colors: 160.3ms -> 13.1ms
- float images: 86.2ms -> 11.1ms
- float images, separate colors: 162.9ms -> 17.4ms
This also fixes curious "one black pixel row" in the middle of the
waveform, which was caused by the code spreading 256 possible luma
values over "off by one" vertical range:
Pull Request: https://projects.blender.org/blender/blender/pulls/115579
Sequencer timeline UI repainting is 3x-4x faster now, for complex
timelines. On Sprite Fright Edit data set, with whole timeline visible
(2702 strips), repainting the timeline UI with all overlay options
(waveforms, offsets, thumbnails etc.):
- Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 62ms -> 18.6ms (16FPS -> 54FPS)
- Mac (M1 Max, Metal): 39.8ms -> 11.5ms (25FPS -> 86FPS)
This is achieved by:
- Avoiding tiny GPU draw calls (i.e. drawing one quad a time), instead
batch all the quads / lines needed by the timeline display into
series of about-1000 quads per draw.
- For retiming keys display, batch their keyframe point drawing too.
- For audio waveform overlay display, change it to draw batched quads
instead of alternating between line strips and triangle strips. This
actually changes how the waveform looks like (implements #115274)
and fixes some visual issues with waveforms too.
- For fcurve overlays, also draw them as batched quads.
While at it, this also fixes an issue where while dragging strips over
other strips, their text labels would look as if they are behind the
background strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/115311
Caused by error in refactor commit 4d668e6825. Offsets are drawn
outside of strip boundary, but strip content range in drawing context
is clamped by handles, so nothing was drawn.
Also this feature was not working, when using solo feature. This was
caused by another refactor e39cc78313. `special_seq_update` global
variable was declared in both files after splitting them, but set only
in one of them. Use `ED_sequencer_special_preview_get()` instead of
accessing variable directly.
Caused by bfe6128748.
The split frame logic actually became inverted in the update:
when the cursor position is true, then the frame is supposed
to be initialized in the invoke().
The menu does not use cursor position, so the code path where
the frame is retrieved from the RNA properties was used, and
the frame was never initialized in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/114973
Caused by 0e01667e25 .
Above commit changed it so that operator properties (set from python)
were ignored for `split_frame` & `split_channel` in case
`use_cursor_position` is False.
Should be the other way around.
Pull Request: https://projects.blender.org/blender/blender/pulls/114905
Selected active strip highlights effect inputs and input channels for
multicam strips. This was done as 3rd pass in `draw_seq_strips()`.
4th pass was highlighting strip when doing solo preview.
Now this is added to a column of functions in `draw_seq_strip()`.
Highlighting effect input and solo preview is done when drawing actual
highlighted strip, but this is still done via alpha blending.
Highlighting multicam has to be done as alpha blending since this is
done by drawing rectangle over whole channel.
Originally code iterated twice over whole listbase with a lot of
preconditions to draw unselected, then selected strips.
Use `sequencer_visible_strips_get()` to get vector of visible strips,
split iteration in 2 separate loops.
Also move `special_seq_update` case to own function.
Use `VectorSet`, `Vector` or `Span` instead of `SeqCollection` struct.
It is now possible to use native `for` loops and `SEQ_ITERATOR_FOREACH`
macro can be removed.
Another feature is, sets of strips no longer needs to be freed. However,
this poses a limitation, that query functions can not be used in case,
where these sets need to be available outside of scope where they are
created.
Pull Request: https://projects.blender.org/blender/blender/pulls/111909
Mistake in 4d668e6825. `draw_seq_strips()` would use
`UI_view2d_view_orthoSpecial()` to only scale drawing horizontally, but didn't
reset the matrix state for normal view-space drawing. Result is that the
preview range drawing would be broken, and so were add-ons using the
`POST_VIEW` draw callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/114285
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Last key is drawn on the right edge of the strip, but that is end of
the frame, which it should be bound to. Because of this, drawing code
and operators must consider, that this key is always displaced.
This was not done in 86a0d0015a and caused issues like #113755 that was
fixed incorrectly.
When retiming key is added to frame before strip starts, this causes
crash on null dereference. After adding null check, this creates
retiming data, even though operation is not valid. To prevent creating
empty retiming data, `SEQ_retiming_data_ensure()` is only executed, when
operator actually adds a keyframe.
These callbacks were named for the purpose of drawing (and that's probably
their main use case still), but nothing limits them to be used for that only.
They can be useful for non-drawing related things, essentially they act as
drop-box entering and exiting event handlers. Reflect that in the name, so also
more clear when they will be called, as opposed to what they are typically used
for. Drop-boxes already have such event handler callbacks, this makes their API
naming more consistent.
Also better differentiates between drawing and handling callbacks, the
difference matters (attempting to draw during handling won't work).
Exposed by cba9f47562 (but actually caused by 4d668e6825 I think).
Because of 4d668e6825 , the `StripDrawContext` `content_start` &
`content_end` were wrong for hold still regions.
These wrong extends were then used in cba9f47562 .
Now actually update `StripDrawContext` `content_start` & `content_end`
when hold still regions are in play (instead of just calling the right
functions [but not using their return values]).
Pull Request: https://projects.blender.org/blender/blender/pulls/113494
Move the three current 'status variables' (stop, update and progress)
into a single 'WorkerStatus' struct. This is cleaner and will allow for
future workin this area without having to edit tens of 'startjob'
callbacks signatures all the time.
No functional change expected here.
Note: jobs' specific internal code has been modified as little as
possible, in many cases the job's own data still just store pointers to
these three values. Ideally in the future more refactor will be using a
single pointer to the shared `wmJobWorkerStatus` data instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/113343
For some reasons, `WM_jobs_stop` and `WM_jobs_kill` would use their own
'type' of function pointer - and not even a matching one!
Among (many) other reasons why this was bad, it required very stupid
casting from code using these functions - and made editing wmJob `startjob`
signature needlessly complicated.
This is because the menu entry was using different operator
properties from what the shortcut is defined for. It was needed
to make it so an operator which is called from the menu does not
have dependency on the mouse location.
Now it is achieved by resolving MOUSE side to RIGHT from the
operator's exec().
Ref #112598
Pull Request: https://projects.blender.org/blender/blender/pulls/113143
- "Tapping Alt...": remove newline in tooltip.
- Add descriptions for the From Left and From Right of the Shear
Keyframes operator's direction items, instead of just "foo":
- "Shear the keys using the left key as reference", and
- "Shear the keys using the right key as reference".
- "Affects the value" -> "Affect", use the imperative.
- "Increase or decrease the value of selected keys \n
in relationship to their average"
-> "Scale selected key values by their combined average":
remove the newline and rephrase the unclear description. New
description by Harley Acheson.
- "Redefine equalizer graphs": this is an operator name, it should be
title case.
- "USD Skeleton Import" warning: inconsistent whitespace.
- "%s: Joint weights and joint indices size mismatch size mismatch for
prim %s": remove duplicated "size mismatch".
- "USD export: couldn't copy texture tile from %s to %s": remove
duplicate whitespace, change "couldn't" to "could not" to respect
the style guide.
- "Temp. Diff." -> expand the abbreviation to "Temperature Difference"
- "Registering node tree class:" do not use formatting just to reduce
redundancy in a few messages, but write it explicitly each time.
This is more legible, and much better for translations.
- "Absolute time alignment while translating" -> "Absolute time
alignment when transforming keyframes" because this applies to all
transforms, not translation only.
- "# characters defines the [...] length of frame numbers" ->
"define" (typo), "padding" is more specific than length.
Pull Request: https://projects.blender.org/blender/blender/pulls/112975
Currently retiming is quite awkward, when you need to retime multiple
strips strips in sync. It is possible to use meta strips, but this is
still not great. This is resolved by implementing selection.
General changes:
Gizmos are removed, since they are designed to operate only on active
strip and don't support selection.
Transform operator code is implemented for retiming data, which allows
more sophisticated manipulation.
Instead of drawing marker-like symbols, keyframes are drawn to
represent retiming data. Retiming handles are now called keys. To have
consistent names, DNA structures have been renamed.
Retiming data is drawn on strip as overlay.
UI changes:
Retiming tool is removed. To edit retiming data, press Ctrl + R, select
a key and move it. When retiming is edited, retiming menu and
context menu shows more relevant features, like making transitions.
Strip and retiming key selection can not be combined. It is possible to
use box select operator to select keys, if any key is selected.
Otherwise strips are selected.
Adding retiming keys is possible with I shortcut or from menu.
Retiming keys are always drawn at strip left and right boundary. These
keys do not really exist until they are selected. This is to simplify
retiming of strips that are resized. These keys are called "fake keys"
in code.
API changes:
Functions, properties and types related to retiming handles are renamed
to retiming keys:
retiming_handle_add() -> retiming_key_add()
retiming_handle_move() -> retiming_key_move()
retiming_handle_remove() -> retiming_key_remove()
retiming_handles -> retiming_keys
RetimingHandle -> RetimingKey
Retiming editing "mode" is activated by setting `Sequence.show_retiming_keys`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109044
This PR fixes an issue with the NVIDIA 3000/4000 series cards. The cause
might be that when blending is turned off and the fragment output has an alpha
of 0.0 the fragment might be discarded. This is a guess of course.
By setting the Alpha to 1.0 for scopes and enabling alpha blending when
drawing the meta data text seems to fix the issue.
Fixes#110976
Pull Request: https://projects.blender.org/blender/blender/pulls/112665
