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
Regression caused by 9e4c26574a.
Add strip stack as a key to the final cache.
Use the pointer to the list of sequences, as it is the easiest one to
obtain in all places where it is needed. This is slightly different
from the code prior to the 9e4c26574a where strips.last() was used,
but it allows to use the same logic in the prefetch job.
Pull Request: https://projects.blender.org/blender/blender/pulls/141778
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
Make display channel part of the key for the final cache.
The prefetch uses display channel of 0, which is the default. It might
need to be adjusted, but it is unclear whether it was behaving different
prior to the 9e4c26574a.
Pull Request: https://projects.blender.org/blender/blender/pulls/141670
If render settings resolution scale had lowered resolution, cached
images from render image/animation session could "stay around"
and be incorrectly used in the VSE preview area. Two cases I found are
fixed here:
- Intra-frame cache was not flushed upon actual final resolution
change,
- "Source images" for effect/scene strips were not removed when
requested resolution no longer matches their rendered resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/141297
Before this change prefetching would not work correctly with only RAW
caches. The RAW caches wouldn't previously be emptied either if
switching them off while prefetching was turned on.
Now the prefetch will start prefetching from the start frame if it hits
the end frame and still have cache space to spare. This improves
playback when playing loops. It also makes it possible for end users to
define an area to pre-fetch by setting the preview range.
New VSE cache implementation (!137926) uses the same eviction
logic for the source image ("raw") cache as for the final frame cache --
remove the frames furthest away from the playhead.
However, source image cache keys are source media frames, not timeline
frames, so this was not working correctly when strips are not at
timeline start.
So, for each cached entry record the strip-start-relative timeline
frame that the entry was created at. This takes care of things like
retiming, reversed frames etc. And also makes the cached frames
visualization more correct in presence of frame reversal etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/139667
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
