This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
As the individual commits say:
- Use Set instead of GSet for tracking proxy builder processed paths
- Use Vector<MovieIndexFrame> to store entries in MovieIndex
- Clearer stdout/stderr printing in movie proxy generation
- Instead of unlink(), use BLI_delete() which does proper utf8 path
conversion on Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/132174
This renames the `Strip` struct to `StripData` and also renames
the `Sequence::strip` member to `Sequence::data`.
This is a first step towards naming the `Sequence` struct to `Strip`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132165
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
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
