VSE cache processing was handling thumbnail generation requests in
parallel, however often that was resulting in CPU core over-subscription
that negatively affects user interface smoothness. Process requests
serially; some parts of image/video loading are internally multi-threaded
already. This makes thumbnails load somewhat slower, but while that
is happening the rest of blender feels much smoother, and the CPU
fans don't spin up as much.
Additionally, make the video thumbnail loading code use smallest
available proxy file, if present. This was overlooked in the original
new thumb cache implementation (!126405).
SpriteFright timeline edit v135 (mostly JPG images, some movies),
loading thumbnails for the whole timeline on Ryzen 5950X (Windows):
- 4.2.1: 35 seconds, CPU usage ~35%, UI smooth
- Main: 13 seconds, CPU usage ~90%, UI choppy
- This PR: 19 seconds, CPU usage ~35%, UI smooth
Manually made timeline with 10 video files:
- 4.2.1: 12 seconds, CPU usage ~50%, UI smooth
- Main: 6 seconds, CPU usage ~100%, UI choppy
- This PR: 9 seconds (no proxies) / 4 seconds (with proxies), CPU usage
~50%, UI smooth
Candidate for 4.5.x backport
Pull Request: https://projects.blender.org/blender/blender/pulls/144120
Use the form "Processing something..." (gerund, sentence case,
ellipsis) for running jobs progress label, according to Blender's
Human Interface Guidelines.
Pull Request: https://projects.blender.org/blender/blender/pulls/141573
This PR switches out the internal scene context function
used from the sequencer. This is done in preparation for
#140271.
Using a separate context function allows us to keep the
existing `context.scene` to refer to the active scene
and use a separate context member to refer to the
sequencer scene in the workspace (which is added in #140271).
Previous attempts simply overrode the `context.scene`
to refer to a different scene than the active one in the window.
This has two issues:
1) Any operator that wants to use the active scene in the window
can't do it in the context of the sequencer. This is a problem for
example for poll functions of operators that don't have anything to
do with the sequencer.
2) For better or for worse, Blender expects the `context.scene` to
always exist. For the sequencer, we'd like to possibly have no
sequence selected.
Using a different context member for the sequencer has some
advantages:
1) Although we have to change quite a few places, it's limited to the
sequencer. We don't have to change other parts of Blender to make
things work.
2) It allows us to prepare for the future when we might want to
separate the VSE from the scene. This is a step in that direction.
Having a different context function makes it easy to find the places
that would need to be refactored.
Pull Request: https://projects.blender.org/blender/blender/pulls/141271
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
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
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
