While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
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
This implements the update cache described in T95401.
The cache is currently only used for drawing strokes and
sculpting (using the push brush).
**Note: Making use of the cache throughout grease pencil will
have to be done incrementally in other patches. **
The update cache stores what elements have changed in the
original data-block since the last time the eval object
was updated. Additionally, the update cache can store multiple
updates to the data and minimizes the number of elements
that need to be copied.
Elements can be tagged using `BKE_gpencil_tag_full_update` and
`BKE_gpencil_tag_light_update`. A full update means that the element
itself will be copied but also all of the content inside. E.g. when a
layer is tagged for a full update, the layer, all the frames inside the
layer and all the strokes inside the frames will be copied.
A light update means that only the properties of the element are copied
without any of the content. E.g. if a layer is tagged with a light
update, it will copy the layer name, opacity, transform, etc.
When the update cache is in use (e.g. elements have been tagged) then
the depsgraph will not trigger a copy-on-write, but an update-on-write.
This means that the update cache will be used to determine what elements
have changed and then only those elements will be copied over to the
eval object.
If the update cache is empty or the data block was tagged with a full
update, we always fall back to a copy-on-write.
Currently, the update cache is only used by the active depsgraph. This
is because we need to free the update cache after an update-on-write so
it's reset and we need to make sure it is not freed or read by other
depsgraphs.
Co-authored-by: @yann-lty
This patch was contributed by The SPA Studios.
Reviewed By: sergey, antoniov, #dependency_graph, pepeland, mendio
Maniphest Tasks: T95401
Differential Revision: https://developer.blender.org/D13984
Copy-on-write data blocks could be referenced from python but were not
properly managing python reference counting.
This would leak memory for any evaluated data-blocks accessed by Python.
Reviewed By: sergey
Ref D12850
This reverts commit 0558907ae6.
Based on discussion with Sergey, having Python references to un-expanded
data should not happen - this change needs to be reconsidered.
Started to happen after recent fix for T72632.
Was caused by runtime fields backup doing an early exit in the case the
given ID was never expanded by the Copy-on-Write mechanism, but it was
not done int the backup restore function (since it was not possible to
know "locally").
Now both init() and restore() will do an early exit when the ID had
nothing to be backed up.
The issue was caused by special handling of animation update after
manual edits in frame_post handler: to avid loss of manual edits
done on top of animated property. This was done as a separate pass
for non-animation update after frame_post did modifications.
This caused some other side-effect: non-modified animated property
was re-setting to the value which is used in the viewport.
Idea of this solution is simple: preserve values which came from
animation update through copy-on-write process. The actual process
of this is a bit involved: need to decode RNA path and do it twice
since f-curve might point to a sub-data which pointer will change.
Since this is only done for non-active depsgraph (aka depsgraph
used for render pipeline) this is probably fine since all this
extra overhead is just a fraction of overall render process.
Differential Revision: https://developer.blender.org/D6330
