Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Pass key that is being removed to `seq_cache_relink_keys()`. This allows
to remove checks before calling the function. Also makes it possible to
assert, that links are actually pointing where they should be.
Use `BLI_ghash_insert` instead of `BLI_ghash_reinsert` to store images.
VSE links stored cache keys for each frame in style of linked list.
These links must be maintained when any image/key is removed from the
cache. Reinserting can free key without proper relinking, which would
lead to accessing this freed key when cache limiting frees images in
a frame.
This should not happen since reinserting is prevented in
`seq_cache_put()`, but it's safer to assert, that key is not stored in
hash instead.
Doing so avoids having duplicated logic for working with pixel
data which is being passed throughout the render pipeline.
Notable changes:
- ImBug can now store GPU texture.
This is not very finished part of the API, which will be
worked further to support tiling for very-high-res images.
- Implicit sharing is removed from the image buffer, as it is
no longer needed.
There should be no functional changes on user level with this
change.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109788
In some cases, freeing the image cache keys would not update
next/previous links - causing future updates to reference freed memory.
Also assert the `last_key` is never points to freed memory.
It was only used by OpenEXR and Iris images, and saving the Z Buffer
in those formats was disabled by default. This option comes from the
times prior to the addition of the Multilayer EXR.
It also worth noting that it was not possible to save Iris with Depth
pass from Blender as internally it is called IRIZ format and it was
not exposed. But even after exposing this format option something still
was missing as saving and loading ITIZ did not show up the Depth pass.
The reason of removal is to make it a more clear match of the ImBuf
with a render pass, and use it instead of a custom type in the render
result and render pass API. This will simplify the API and also avoid
stealing buffers and making shallow copies when showing the render
result.
For the cases when Depth is needed a Multilayer EXR is to be used,
as most likely more than just the Depth will be needed.
On a user level this change:
- Removes the "Z Buffer" option from the interface.
- It preserves existing sockets in compositor nodes, but it will
output black image. Also changing the image data-block will
remove the socket unless a Multilayer EXR with Depth pass image
is selected.
- Removes "Depth" socket of the Viewer and Composite nodes.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109687
This happened, because `SEQ_retiming_find_segment_start_handle()` does
not consider last handle as valid return value, so it was never checked
against.
Before this change the ImBuf struct had dedicated fields for the
buffer data. Now the color space is stored inside of the struct
which wraps around the buffer information.
This only changes the field placement, without changing the way
it is handled. In the future one might imagine that operations
like stealing buffer data should null-ify the buffer colorspace
pointer. Such changes would need to have more accurate thinking
before implementation.
Should be no functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109291
This gizmo is now responsible for drawing labels with speed of retimed
segments. By clicking on the value it is possible to type in new speed,
which is more convenient, than dragging handles by hand.
Note: Due to granularity of frames, the precise value may not be
respected.
Pull Request: https://projects.blender.org/blender/blender/pulls/108422
Freeze frames can be added now using retiming tool with no need to hold
splitting strips or using hold offsets. To use this feature, add
retiming handle where you want to freeze the frame, hold ctrl key and
drag the handle. It is not possible to freeze frame of transition handle
and it is not possible to add transition to or from freeze frame.
Retiming system would handle these cases, but they are not useful in
practice.
When freeze frame is created, start handle of frozen segment is flagged
as `FREEZE_FRAME`. Most handling is similar to `SPEED_TRANSITION`
type handle. For evaluation, there is no special case for this type, as
it's just 2 handles with same `retiming_factor` value. It is possible to
recreate this behavior without using freeze frame feature by adding
handle between 2 consecutive content frames, but this would not be
recognized by UI or treated as freeze frame segment/handle.
Eventually this feature should replace hold offsets, leaving `Sequence`
struct with single offset type, see PR 105620 for reference.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Own regression caused by [0] made to ensure the string was initialized,
without accounting for it being static & reused between calls.
Replace static variables with a struct that's passed to the function,
this explicitly shares state between calls as this static variable use
depended on BKE_scene_multiview_view_prefix_get always clearing prefix
variables with a zero view_id so future calls would also be cleared.
While this non-obvious behavior could be documented,
use more straightforward logic.
[0]: bdad2c0595
