The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135747
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
There's no point in having non-threaded image color space conversion functions.
So merge the threaded and non-threaded functions and clarify names while at it:
- IMB_colormanagement_transform & IMB_colormanagement_transform_threaded
-> IMB_colormanagement_transform_float
- IMB_colormanagement_transform_byte & IMB_colormanagement_transform_byte_threaded
-> IMB_colormanagement_transform_byte
- IMB_colormanagement_transform_from_byte & IMB_colormanagement_transform_from_byte_threaded
-> IMB_colormanagement_transform_byte_to_float
These places were doing single-threaded colorspace conversion previously, and
thus now are potentially faster:
- IMB_rect_from_float (used in many places)
- EXR image "save as render" saving (image_exr_from_scene_linear_to_output)
- Object baking (write_internal_bake_pixels, write_external_bake_pixels)
- General image saving, clipboard copy, movie preparation
(IMB_colormanagement_imbuf_for_write)
- Linear conversion when reading HDR images/movies
(colormanage_imbuf_make_linear)
- EXR multi-layer conversion (render_result_new_from_exr)
For one case I benchmarked, which is to render out a 2D stabilized 10 bit input
movie clip out of VSE, the total render time went from 49sec down to 44sec
(Ryzen 5950X), one of the single-threaded parts was the colorspace conversion
in the movieclip code.
Pull Request: https://projects.blender.org/blender/blender/pulls/135155
with #133413 the intent was that VSE Text strips would not use the
fallback font stack if using a custom (non-default) font. However this
determination was done by comparing the font id. This was very weak as
the id can vary quite a bit within the first few fonts. This PR instead
adds a BLF function (BLF_is_builtin) that uses BLF_DEFAULT font flag
instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135014
If a sequencer text strip is using a custom font (not the default one)
then don't use the fallback font. This adds a new font flag to disable
the use of fallback.
Pull Request: https://projects.blender.org/blender/blender/pulls/133510
Instead of passing the `scene`, pass a pointer to the `Editing` struct.
This is the struct that owns the `StripLookup` in its `runtime`
so there isn't a good reason to use the `scene` pointer here
anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/134743
This removes the `scene` parameter of
`SEQ_time_get_rounded_sound_offset` and
`SEQ_time_media_playback_rate_factor_get`.
Instead, we now pass the `frames_per_second` directly.
This is an attempt at getting less of the code to be
scene dependent.
Pull Request: https://projects.blender.org/blender/blender/pulls/134741
This main thread check was introduced in 4536a4c610. At the time OpenGL
only ever worked in the main thread, but that limitation was lifted in
Blender 2.80.
With this operator being converted to use the jobs system, it now needs
to work in non-main threads. Note that this code does not run in parallel
with main thread drawing anyway, because of WM_job_main_thread_lock_acquire
and draw manager locks. What changed is that we can now activate OpenGL
contexts on other threads.
Pull Request: https://projects.blender.org/blender/blender/pulls/134696
All 2D vectors related to image transform code were changed to float2.
Previously, it was decided, that 4x4 matrix should be used for 2D
affine transform, but this is changed to 3x3 now.
Texture painting code did rely on `IMB_transform` with 4x4 matrix.
To avoid large changes, I have added function
`BLI_rctf_transform_calc_m3_pivot_min`.
Main motivation is cleaner code - ease of use of c++ API, and avoiding
returning values by arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/133692
Translating keys when speed transitions are present with media not
matching scene FPS causes incorrect behavior.
This was caused by multiple issues - in some places media vs scene FPS
mismatch was not accounted for and multiple instances of presision loss
due to casting float values to integer.
Pull Request: https://projects.blender.org/blender/blender/pulls/131911
Use float for intermediate values when calculating speed or timeline
frames.
More details on precision improvement itself: In some cases, setting
strip speed to say 70% would result in actual speed being set to say
69.5%. With this change, the number would be closer or equal to 70%.
There few tangentially related changes:
- `SEQ_retiming_key_speed_get` was changed so both functions work in
same time domain.
- `SEQ_retiming_key_speed_set` now expects speed as float factor
instead of percentage. This is consistent with get function return
value.
- Improve variable names, for better code readability.
Pull Request: https://projects.blender.org/blender/blender/pulls/131782
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
10/12bpp movie writing code assumes that input image is properly
floating point for these cases. That is always true for regular
rendering, however VSE can produce 8bpp images, if there
are no float/HDR strips in there. Make these convert into a float
image in the render pipeline when needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/133802
This PR explicitly declares integer type for `image_center_offs`, which
formalizes accidentally implemented correct behavior. Previously type
was float, all rhs types in expression were integers, so result was int
cast to float.
Comment is also added clarifying why integer must be used - float may
cause images to be interpolated, even when translation is set to 0.
There should be no functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/133573
This PR adds new RNA properties that deprecate and replace any `sequence` property.
The old prooperties are still there and fully functional, but the description is changed
to indicate that these will be removed in the future and that the new properties should
be used instead.
| Deprecated property | Replacement property |
| --------------------------------- | ----------------------------------- |
| `context.active_sequence_strip` | `context.active_strip` |
| `context.selected_editable_sequences` | `context.selected_editable_strips` |
| `context.selected_sequences` | `context.selected_strips` |
| `context.sequences` | `context.strips` |
| `SequenceEditor.sequences` | `SequenceEditor.strips` |
| `SequenceEditor.sequences_all` | `SequenceEditor.strips_all` |
| `MetaStrip.sequences` | `MetaStrip.strips` |
Previously, rna paths for animation data on strips started with `sequence_editor.sequences`.
This PRadds versioning for the rna paths to make sure to use
the new naming scheme. This does mean that in previous versions of blender,
the animations don't show but the data is not lost (even if the file is saved in the older version).
Also do some cleanup of existing python scripts inside the source to use the
new properties.
Part of #132963.
Pull Request: https://projects.blender.org/blender/blender/pulls/133156
Part of Code Quality Project outlined in #130975.
This patch eschews warning messages urging the user to "select all
related strips" when copying or creating new metastrips and instead
automatically includes those related strips in the operation.
- Attempting to copy or create a metastrip with no strips selected no
longer delivers a warning.
- When copying strip(s), if there are related effect chains, they will
be automatically selected and included in the copy if the operation
succeeds.
- The decision to select related strips was intentional, as it allows
the user to easily see the entire effect chain and thus which strips
were copied.
- When creating a new metastrip, if there are related effect chains,
they will automatically be included in the resulting metastrip.
- This is done using a new
`SEQ_query_strip_connected_and_effect_chain()` iterator. This
iterator is only used for metastrips, and not copying, since the
user may wish to only copy single strips in a connection, but
connected strips should always stay together in a metastrip/seqbase.
Pull Request: https://projects.blender.org/blender/blender/pulls/132930
The rest of blender does handle multi-layer EXR images, using the
"combined" or RGBA/RGB layers when the visual result is needed. Make
VSE do the same.
While fixing this, I found several issues in other not well tested code
and had to fix them:
- IMB_buffer_float_from_float_threaded was wrongly using source channels
as destination channels, producing garbage result.
- IMB_scale_into_new was not assigning channels to destination image.
Pull Request: https://projects.blender.org/blender/blender/pulls/132790
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
Depending on proxy size and scaling factor, the "does proxy cover
whole screen" code was producing wrong results, due to mismatched
resolutions it was working on: SeqRenderData at that point contains
proxy resolution (reduced), but SEQ_image_transform_final_quad_get
works at full resolution. The produced quad needs to be scaled down
to what the render context is operating at.
