With factory settings, steps to reproduce were:
* Select "Collection 1" (in "RenderLayer")
* Delete
It might crash at this point, although maybe this crash is ASAN only.
However, this was also doing some weird things that I've corrected now. It
called outliner_build_tree in an operator callback. This should only be
called in the main redraw function or so, not in regular handlers.
Instead, we manually cleanup the tree to keep it valid.
This is quite common to have 64GB memory now, and even 128. There is no reason
to add any artificial caps on the cache and undo memory here. We can not protect
against using too much memory in one cases and allow use of full computer
potential in others.
Now 32 bit will use 2GB max (as it used to be), but 64bit will use whatever
number of megabytes fits into integer.
Reviewers: campbellbarton, mont29
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D2972
This reverts change to BKE_brush_add,
callers now remove the extra user.
Note this isn't very convenient for callers but
is consistent with other ID types.
In the future we will probably remove this and have new
ID's created with zero users.
When using a tablet, detecting absolute motion only worked
when activating a tool with the tablet.
Pressing Enter to run a tool for e.g. would use relative motion.
Now store is_motion_absolute in the event,
set for new events based on the most recent motion events.
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.
