blender
/
blender
136
407
Fork 589
Code Issues 6.3k Pull Requests 777 Projects 19 Wiki Activity

Anim: thread remake_graph_transdata #119497

Merged
Christoph Lendenfeld merged 13 commits from ChrisLend/blender:thread_remake_transdata into main 2024-04-09 11:46:17 +02:00
Conversation 0 Commits 13 Files Changed 1 +12 -5
1 changed files with 12 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
source/blender/editors/transform/transform_convert_graph.cc
View File

@ -889,9 +889,17 @@ static void remake_graph_transdata(TransInfo *t, const blender::Span<FCurve *> f
SpaceGraph *sipo = (SpaceGraph *)t->area->spacedata.first;
const bool use_handle = (sipo->flag & SIPO_NOHANDLES) == 0;
/* Sort and reassign verts. */
for (FCurve *fcu : fcurves) {
if (fcu->bezt) {
/* The grain size of 8 was chosen based on measured runtimes of this function. While 1 is the
Sybren A. Stüvel commented 2024-04-09 11:14:44 +02:00
Outdated
Review
Copy Link

Add a comment that explains how the 8 got here.

Add a comment that explains how the 8 got here.
* fastest, larger grain sizes are generally preferred and the difference between 1 and 8 was
dr.sybren marked this conversation as resolved Outdated
Falk David commented 2024-03-28 14:59:40 +01:00
Outdated
Review
Copy Link

Looks like you don't need the index here, so it might be better to use parallel_for_each. Of course, that's only if you actually want a grain size of one.

Looks like you don't need the index here, so it might be better to use `parallel_for_each`. Of course, that's only if you actually want a grain size of one.
Iliya Katushenock commented 2024-03-28 15:01:10 +01:00
Outdated
Review
Copy Link

Even with grain size 1, range can have any size. But i wonder if this will be better to test parallel_for_weighted here.

Even with grain size `1`, `range` can have any size. But i wonder if this will be better to test `parallel_for_weighted` here.
Hans Goudey commented 2024-03-28 15:07:44 +01:00
Outdated
Review
Copy Link

parallel_for_each uses a different algorithm internally that has more overhead. AFAIK it will always give each element its own thread. I think it's typically only suitable for much more expensive tasks.

`parallel_for_each` uses a different algorithm internally that has more overhead. AFAIK it will always give each element its own thread. I think it's typically only suitable for much more expensive tasks.
* only minimal (~330ms to ~336ms). */
blender::threading::parallel_for(fcurves.index_range(), 8, [&](const blender::IndexRange range) {
for (const int i : range) {
Sybren A. Stüvel commented 2024-04-09 11:15:39 +02:00
Review
Copy Link

if (!fcu->bezt) { continue; }

Gitea already doesn't present this as "it's all the same, just indented", so I think it's fine to restructure the code a bit further for readability.

`if (!fcu->bezt) { continue; }` Gitea already doesn't present this as "it's all the same, just indented", so I think it's fine to restructure the code a bit further for readability.
👍 1
FCurve *fcu = fcurves[i];
if (!fcu->bezt) {
continue;
}
BeztMap *bezm;
/* Adjust transform-data pointers. */
@ -907,10 +915,9 @@ static void remake_graph_transdata(TransInfo *t, const blender::Span<FCurve *> f
* (perhaps this could be done using the beztmaps to save time?). */
sort_time_fcurve(fcu);
/* Make sure handles are all set correctly. */
testhandles_fcurve(fcu, BEZT_FLAG_TEMP_TAG, use_handle);
}
}
});
}
static void recalcData_graphedit(TransInfo *t)