Now that attributes use implicit sharing, copying CurvesGeometry
is relatively cheap, and the complexity of this function isn't worth
the remaining optimization of avoiding user count updates.
These reports were embedded in the window manager DNA,
but they were always cleared when reading it from files. It's clearer
to just not store the reports in files at all. I also moved the reports
initialization and freeing to the constructor and destructor of the
runtime class.
This is the only place `ReportList` was embedded in DNA, so
after this we can move that to use C++ features if we want.
Pull Request: https://projects.blender.org/blender/blender/pulls/118329
The compositor assumes the entire viewport as its compositing space even
in camera view. The current design decision was to limit the compositing
space by the camera region only if the camera passepartout is opaque,
that is, areas outside of the camera are not visible.
This patch changes that behavior to always limit the compositing space
by the camera region. The downside is that areas outside of the camera
will be left uncomposited.
This is useful to match viewport compositing to final render compositing
in terms of maintaining the same space, but not necessarily the same
resolution. However, this still has the limitation that space will be
different when the camera region intersects the viewport, since we only
composite their intersection in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/118241
In some/many cases, an `ImBuf` is allocated, and all the pixels are
immediately filled by some code. Doing the memory clear within allocation
is just memory traffic for no good reason.
Add a flag to skip initialization of ImBuf pixels (IB_uninitialized_pixels)
and use that in some parts of VSE effects/rendering/cache/scopes, as well
as image loading code.
Rendering out VSE movie, on Windows/VS2022/Ryzen5950X:
- Sprite Fright: 443sec -> 414sec (takes 93% of previous time)
- Gold previs: 367sec -> 325sec (takes 88% of prev time)
Pull Request: https://projects.blender.org/blender/blender/pulls/118321
The GPU compositor does not take the border region into consideration,
which means it reads more than it should, leading to corruption. Fix
this by taking the border region into account when computing render
width and height.
The size of the string in bytes happened to match the the pointer size
on 64bit systems, nevertheless the logic was wrong would would fail on
32bit systems. Also use a character to search the string instead of a
single character string.
ffmpeg's libswscale is used to do RGB<->YUV conversions on movie reading
and writing. The "context" for the scale operation was being created
and destroyed for each movie clip / animation. Now, maintain a cache
of the scale contexts instead.
E.g. in Gold edit, it only ever needs two contexts (one for reading
source movie clips since they are all exactly the same resolution
and format; and one for rendering the resulting movie).
During playback, on some of the "slow" frames (camera cuts) this
saves 10-20ms (Windows, Ryzen 5950X). Rendering whole movie goes
from 390sec to 376sec.
Pull Request: https://projects.blender.org/blender/blender/pulls/118130
Relatively basic and straightforward implementation.
Further optimizations are possible (and needed), especially regarding
the handling of caches.
Notes:
* All drawings are stored in each undo step. This is needed (also for
Reference drawings), in case some drawings are added, removed or
re-ordered between undo steps.
* The whole tree of layers is copied as-is, using the C++ classes copy
constructors, so they only handle what these constructors copy
(noticeably, the `Layer` copy constructor does not currently handles
masks?).
* The active layer pointer is stored and restored by its name.
* The layer customdata is also duplicated using standard `BKE_customdata`
API.
Pull Request: https://projects.blender.org/blender/blender/pulls/117072
This commit essentially:
* Remove the 'delete single ID' code path.
The multi-deletion code has now be around for a long while, so we
should be able to assume it is mature enough. It is also several times
faster when deleting a lot of IDs at once.
* Move away from using `LIB_TAG_DOIT` ID tag in internal code, using a
Set instead to store the IDs to be deleted.
Potential side-effects:
* The 'delete single ID' codepath (removed by this commit) was making
some dangerous assumptions regarding order of IDs in Main and 'strong'
dependencies between them. While these assumptions where presumably
correct in current code/data model context, they were logically wrong
and could have randomly cause bugs in the future.
* The sanitiing check on usercount performed in the case of the single
ID deletion cannot be done anymore. Should not be that usefull
anymore, as there are other places where IDs usercounts are validated.
* Performances:
* The batch-deletion did not show any significant difference in speed.
* Massively deleting IDs one by one however, showed a surprising 10%
speedup.
Pull Request: https://projects.blender.org/blender/blender/pulls/118283
Existing code would allow tagging on request IDs which had a 'never
null' usage potentially cleared by the remapping operation (e.g. if an
Object obdata would have been set to `nullptr`).
While this worked for the current extremely restricted usecase (ID
deletion), this was not the best design, as it forced the ID remapping
user code to be very careful about its own usages of the `LIB_TAG_DOIT`
tag.
This commit replaces internal tagging by adding such IDs to a Set in
`IDRemapper` class, which user code can then use to find which IDs
(would have) had a 'never null' ID pointer cleared.
There are two additional changes induced by this commit:
* `BKE_libblock_unlink` `do_flag_never_null` parameter is removed.
As it is not used in current codebase, simpler to remove than update
the code to support it.
* `ID_REMAP_FLAG_NEVER_NULL_USAGE` option is renamed to
`ID_REMAP_STORE_NEVER_NULL_USAGE`.
In addition, its behavior is slightly modified:
* Before, the owner ID would systematically be tagged if it had such
'never null' ID usages, regardless of whether said ID usages (would)
have actually been remapped to `nullptr`.
* Now, the owner ID is only added to the `never_null_users` set if its
'never null' usages (would) have been cleared.
This PR adds a new command line argument to validate all statically
defined shaders. It is useful for platform support to understand
what isn't working.
It only checks statically defined shaders. Dynamic shaders (EEVEE/Compositor)
can still be fail.
The report is printed to console. After checking with windows platform and
triaging we could also add it to gpu debug script. There is a risk of adding it there
as it might crash and don't store any output.
Pull Request: https://projects.blender.org/blender/blender/pulls/117326
- Use FunctionRef to avoid passing a separate user_data pointer
- Use std::string in arguments struct
- Add search items in one loop after gathering search items
- Use Vector of unique_ptr for search items instead of linked list
Span is preferrable since it's agnostic of the source container,
makes it clearer that there is no ownership, is 8 bytes smaller,
and can be passed by value.
It is not required to hold the lock of DST when performing
compositing on GPU, as the compositor implementation uses the
GPU module directly, bypassing the draw manager.
However, currently this is known to cause issues on macOS,
and is not yet tested on Windows.
On Linux it works correctly, and avoids lock while compositor
is running.
There could still be a small locking hiccup, when the GPU
context is created and disposed. This needs to be looked
into.
Pull Request: https://projects.blender.org/blender/blender/pulls/118286
Hans Goudey
YimingWu
Sebastian Parborg
Omar Emara
Raul Fernandez
Aras Pranckevicius
Pratik Borhade
Campbell Barton
Jacques Lucke
Sergey Sharybin
Bastien Montagne
Jeroen Bakker
Iliya Katueshenock
Clément Foucault
Harley Acheson