This resolves a performance regression in 2.8x where every edit-mode
update performed an edit-mesh to mesh conversion.
Now the conversion will be lazily initialized if/when it's required.
New BKE_mesh_wrapper_* functions abstract over mesh data access.
Currently only edit-mesh and regular meshes are supported.
In the future sub-surface meshes may be supported too.
Lamps were not tagged with `ID_RECALC_SHADING` when they were updated
from drivers. As a result, Cycles considered the lamp as unchanged. This
is resolved by having a (seemingly non-functional) callback in a new
`LIGHT_UPDATE` depsgraph node.
This patch unconditionally adds the `LIGHT_UPDATE` node + the relation
from the lamp's PARAMETERS node.
Differential Revision: https://developer.blender.org/D7822
Reviewed by: brecht
While investigating T76274, I found crash scenario when playhead is near end
frame and moving a strip. It is not as easy to reproduce, about 5% success
rate, and it will be even harder after rB4066c921fbe5. Exact cause wasn't
identified yet.
I wanted to disable prefetching during modal operator execution in VSE, but
currently I don't have any signalling method in place. Checking for G.moving
seems to resolve this problem, but it doesn't adress root cause of bug.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7820
We define Lossless as CRF 0 (which is usually the best quality and is
working fine with other codecs afaict), but since WebM only allows for
CRF values between 2-32 and actually has a dedicated "lossless" mode, I
suggest using that (it produces large files though, so double-checking
would be welcome).
https://trac.ffmpeg.org/wiki/Encode/VP9#LosslessVP9
Maniphest Tasks: T74443
Differential Revision: https://developer.blender.org/D7800
This bug is not really visible for user. When end frame is reached by
prefetching thread, it doesn't stop and keeps on getting images from
cache.
Add chech for this situation and simplify logic involved in suspending,
so it's easier to read.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7757
Prefetching is stopped in BKE_sequencer_cache_cleanup, but is restarted quickly.
Prefetching has negative effect on performance while rendering.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7751
When rendering another scene, caching in disabled by setting
local_context.skip_cache = true. Precondition checking for this flag was
missing in BKE_sequencer_cache_get and it wasn't first thing to check in
BKE_sequencer_cache_put.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7750
Dummy typo in own recent libquery refactor, of course that one missed
change was on a line not covered by our tests or the production file
used for validation...
Previously this would be enabled when threads were used, but threads are now
basically always in use so there is no point. Further, this is only needed for
guarded allocation with --debug-memory which is not performance critical.
This was already changed for the TBB-based BLI_task_parallel_range in master.
This task local storage should always be initialized from the template, not
copied from another task which may be executing at the time the copy happens.
This may not fix any actual bug, we only use this user data for parallel reduce
and it's not clear that TBB ever calls the copy constructor for that case.
Ref T76858
From what I can see, there are two issues at play in {T76689} and its merged-in report {T76590}:
- In Blender ≤ 2.79 the bone layer dots were updated in the draw code. This ensured the info was up to date before drawing. This is no longer possible, as the drawing code uses evaluated objects, and those should not be written to. This has been addressed in rB709f126e8143 by calling the update function explicitly in various places in the code. The problem is that this wasn't added to all necessary spots.
- When in edit mode, changes are made to the edit bones but not to the 'actual' bones (this is synced when exiting edit mode). This causes undo to mess up the layer indicators.
I think both issues can be addressed by having the dependency graph update the used layer info as part of the armature evaluation. This will make the undo system work properly, and allows the removal of some `BKE_armature_refresh_layer_used()` from various places.
There is still the issue that there are two functions (`BKE_armature_refresh_layer_used()` and `ED_armature_edit_refresh_layer_used()`) that are both responsible for updating `bArmature::layer_used`. This is a trickier thing to solve, though, as the definition of the `EditBone` struct resides in the armature editor module. This means that blenkernel can't iterate over edit bones, but on the other hand the dependency graph shouldn't call any editor functions either. This is why I left the `ED_armature_edit_refresh_layer_used()` calls untouched.
The downside of recalculating `layer_used` from the dependency graph (at least in the way that I did it now) is that it is called every time a user moves a bone in pose mode. This frequency of updates is not necessary.
Differential Revision: https://developer.blender.org/D7709
The interpolation function of the datalayer was misssing so the sculpt
mask data was corrupted every time a subdivision surface modifier was
applied.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7640
That one was a bit more complicated, and is still only partial refactor
(ultimately we want to have a foreach_id callback in SpaceType itself I
think...).
