Blender Git Loki
Git Commits -> Revision c4e88dd
Revision c4e88dd by Sergey Sharybin (master) June 25, 2013, 09:04 (GMT) |
Experimental feature to lock the interface while rendering 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. |
Commit Details:
Full Hash: c4e88dd908e76660be9c9498b96707dabcdc8b96
SVN Revision: 57727
Parent Commit: 6504008
Lines Changed: +86, -5
8 Modified Paths:
/release/scripts/startup/bl_ui/properties_render.py (+1, -0) (Diff)
/source/blender/blenloader/intern/readfile.c (+1, -0) (Diff)
/source/blender/editors/render/render_internal.c (+34, -3) (Diff)
/source/blender/makesdna/DNA_scene_types.h (+2, -1) (Diff)
/source/blender/makesdna/DNA_windowmanager_types.h (+3, -0) (Diff)
/source/blender/makesrna/intern/rna_scene.c (+6, -1) (Diff)
/source/blender/windowmanager/intern/wm_event_system.c (+36, -0) (Diff)
/source/blender/windowmanager/WM_api.h (+3, -0) (Diff)
/source/blender/blenloader/intern/readfile.c (+1, -0) (Diff)
/source/blender/editors/render/render_internal.c (+34, -3) (Diff)
/source/blender/makesdna/DNA_scene_types.h (+2, -1) (Diff)
/source/blender/makesdna/DNA_windowmanager_types.h (+3, -0) (Diff)
/source/blender/makesrna/intern/rna_scene.c (+6, -1) (Diff)
/source/blender/windowmanager/intern/wm_event_system.c (+36, -0) (Diff)
/source/blender/windowmanager/WM_api.h (+3, -0) (Diff)