Object update used to free object-data level bounding box to trigger
it's re-calculation in the future. Such a freeing performed from
object update isn't thread-safe because mesh could be shared between
multiple objects.
Rather than freeing bounding box, tag it's as invalid, this is safe
from threading point of view and also prevents unnecessary memory
re-allocation.
Object-level bounding box is still reallocating, but think we could
change this easily in the future as well.
the report explains the issue in detail, but basically you couldn't know if a mesh was in editmode without checking all the objects that use it.
add `is_editmode` readonly property for all datatypes which support editmode.
also make rna fail to build on implicit function declarations.
Added function called WM_set_locked_interface which does
two things:
- Prevents event queue from being handled, so no operators
or values are even possible to run or change. This prevents
any kind of "destructive" action performed from user while
rendering.
- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.
This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.
Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.
For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.
Currently this option would only make rendering thread-safe, but
in the future more benefits are possible to gain from it. Namely,
if we'll make renderer using it's own graph, this option would
allow to free memory used by 3D viewport graph, which would help
keeping memory usage low (or even would allow renderer not to
copy anything in this case).
Initially thought this change will also allow to free DMs used
by viewport, but we couldn't actually do this. This is because
of modifiers which uses other objects (like boolean), They're
in fact using viewport DM. This is bad because of few reasons.
We currently need to have viewport DM when rendering.
And for sure even in background render viewport DMs are being
calculated. This sounds like 2x computing is needed: one is for
viewport DM and one is for RenderDM.
If we'll have local graphs, we'll be able to compute RenderDMs
only and store them in graph. This would require a bit more of
the memory, but would solve current issues with viewport DM
used for modifiers operands while rendering and it should give
quite noticeable speedup.
Other tools like backing would also benefit of this option,
but rather get approval of current way of locking first.
node materials.
Area and region listener callbacks now get the screen and area pointers passed, so
they can do more fine grained checks to see if redraw is really needed, for example
depending on the 3D view drawtype.
It removes buttons_header.c file, adds a (small) space_properties.py one, with a PROPERTIES_HT_header class, which simply uses the RNA enum to draw the context buttons.
It also fixes that enum, btw, it always featured all contexts, which means you could (try to!) set through RNA invalid contexts...
Thanks to brecht and dingto for the reviews.
are not an accurate representation of the actual node size which is determined by the uiLayout.
Please note that the dimensions calculation depends on the drawing of nodes, so it may not get updated if nodes are not visible in any editor. Also the node height in particular can change dramatically
based on previews, visible sockets, etc.
proposal was to add another special init hack for the viewer node->id, but rather would do it right and so moved all the special init hacks for constant ID backpointers (Scene for RenderLayer, Composite,
Defocus, FileOutput and MovieClip for MovieClip, MovieDistortion and Stabilization nodes). These are now part of the local init callbacks functions of the appropriate nodes, using the new initfunc_api
callback which takes a Context pointer, so they have access to Scene.
Couple of issues here:
- User shouldn't be able to run into dupligroup recursion.
It was checking already when setting a group for dupli.
Added check to operator which adds object to group.
- It's still possible files with recursion are hanging around,
so made simplify function robust to such kind of crap.
