| Age | Commit message (Collapse) | Author |
|---|
|
To clarify term still frame: This is portion of strip that displays
static image. This area can exist before or after strip movie content.
Still frames were implemented as strip property, but this was never
displayed in panel. Only way to set still frames was to drag strip
handle with mouse or using python API. This would set either
`seq->*still` or `seq->*ofs` where * stands for `start` or `end`.
When strip had offset, it can't have still frames and vice versa, but
this had to be enforced in RNA functions and everywhere in code where
these fields are set directly. Strip can not have negative offset or
negative number of still frames.
This is not very practical approach and still frames can be simply
implemented as applying negative offset. Merging these offsets would
simplify offset calculations for example in D14962 and could make it
easier to also deprecate usage `seq->*disp` and necessity to call
update functions to recalculate strip boundaries.
For users only functional change is ability to set negative strip offset
using property in side panel.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D14976
|
|
When handles are moved, job is created only for strips that need to
update first thumbnail.
ref T91618
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
- Move functions that handle animation to own file - `animation.c`
- Refactor `SEQ_offset_animdata` and `SEQ_free_animdata` functions
- Add function `SEQ_fcurves_by_strip_get` to provide more granular
and explicit way for operators to handle animation
- Remove function `SEQ_dupe_animdata`, do curve duplication explicitly
in operator code, which makes more sense to do. Further this function
was also used for renaming strips which makes no sense.
- Refactor usage of function `SEQ_free_animdata` and remove XXX comment.
Now this functiuon is no longer called when `Sequence` data is freed
implicitly, it is done explicitly in high level function
`SEQ_edit_remove_flagged_sequences`
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13852
|
|
Decrease threshold for drawing thumbnails.
This was unintended change in daaa43232d34 that was overlooked.
|
|
This patch changes the thumbnails' height used for image and movie
strips by choosing the proper size according to the VSE's text overlay
settings: i.e. thumbnails use the whole strip's height when no overlay
text is displayed; otherwise, some space is left for the overlay.
Reviewed By: ISS
Differential Revision: https://developer.blender.org/D13043
|
|
|
|
Split thumbnail job in 2 passes. First pass will render visible images
and second part renders set of "guaranteed" equally spaced images.
When viewing larger amount of strips, it is likely that only 1 or 2
images will be rendered in first pass, while in second pass it is up to
30 images.
This results (seemingly) in 3x better performance, but zooming before
set of guaranteed images is done will be slightly more inaccurate.
|
|
During rendering VSE cache is invalidated, so thumbnails would be
removed and thumbnail job would constantly restart.
Even if thumbnails would be preserved, resources should be dedicated
for rendering job.
|
|
Free strip `anim` data immediately after rendering. This doesn't affect
rendering performance, because each new loop would have to seek to start
of strip. Also strips are now freed anyway, but after rendering loop
ends.
With SF edit file, thumbnail rendering used around 60GB of memory.
Now it uses few hundreds MB (depends on movie file resolution, codec,
etc.)
Freeing of strips caused UI to be unresponsive for brief period. This
issue is not removed, but is more spread out so it is less noticable.
|
|
No functional changes.
|
