The idea is to support following: allow doing parallel for on a small range,
each iteration of which takes lots of compute power, but limit such range to
a subset of threads.
For example, on a machine with 44 threads we can occupy 4 threads to handle
range of 64 elements, 16 elements per thread, where each block of 16 elements
is very complex to compute.
The idea should be to use this setting instead of global use_threading flag,
which is only based on size of array. Proper use of the new flag will improve
threadability.
This commit only contains internal task scheduler changes, this setting is not
used yet by any areas.
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
Still not fully working, more work TODO (IDProps are rather tedious to
handle in RNA... :/ ).
Partial fix of T53715: 2.8: Removing keymap items no longer works.
Some shortcuts can now be edited/deleted again, but some remain
mysteriously frozen!
This modify the selection code quite a bit but it's for the better.
When using selection we use the same batching / instancing process but we draw each element at a time using a an offset to the first element we want to draw and by drawing only one element.
This result much less memory allocation and better draw time.
This is a special memory manager that keeps memory blocks ready to send as vbo data.
Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame.
This is why DRWInstanceDatas are sorted in a list for each different data size.
This a small cleanup of something which I think is just a typo anyway.
With all the recent talks of harrassment and groping, I think we better avoid
that within our source code! :)
Reviewers: sergey
Reviewed By: sergey
Tags: #motion_tracking
Differential Revision: https://developer.blender.org/D2979
We now can drag multiple objects at once in the outliner. You we restricted to
working within a single outliner. Be sure to drag from the objects name, not
from its icon (otherwise it will try to parent it).
We don't use the same drag'n'drop system as IDs here. Which although I dislike
allowed for this solution to be local, and not dependent on the entire
drag'n'drop system of Blender.
This is a feature Andy Goralczyk has requested a long time ago.
Kudos for him for his request.
This technically reverts 176698b2eb.
Drag and drop for scene collections requires id for its poll function. However
we were passing the collection as id pointer for outliner_add_element
(which is ok since the function doesn't require a real ID).
I couldn't reproduce the original issue tackled by the forementioned commit so
I'm going ahead and bringing drag and drop back for scene collections.
Note: We already pass the ID for view layer collections as well since we brought
collections into groups.
This is a partial revert of 1f5106de61.
First and firemost, for groups I was checking the wrong flag
(soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS).
Second, the columns were entirely broken for things like Orphan Data.
Third, I tried to have different columns for different `outlinevis`, but we have
bones with only visible and select, modifiers with visible and render, render
passes with enable and another value ... I would rather stay away from this mess
at the moment, and stick to the more obvious bug fix.
Finally, there is a bug (not addressed here) where the whole line is selected,
regardless of the restriction column area. It should be fixed separately.
Result is less noisy ogl renders.
What this patch does:
- the draw loops gets accumulated into the output buffer.
- disable TXAA persmat jittering in ogl render since ogl render already does that.
- make noise texture update correct accross all draw loops. Previously it was reset between each FSAA samples.
- Hashed Alpha materials were outputing their alpha values even if the final pixel has no blending and thus no transparency.
- Opacity was not clamped when using "add closure" nodes.
