[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [57957] branches/soc-2013-depsgraph_mt/ source/blender/blenkernel/intern: Get rid of crazy DAG nodes coloring when doing threaded update

[Sergey Sharybin]

Revision: 57957
          http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=57957
Author:   nazgul
Date:     2013-07-03 12:32:17 +0000 (Wed, 03 Jul 2013)
Log Message:
-----------
Get rid of crazy DAG nodes coloring when doing threaded update

DAG node already has got type field, so we could just check whether
type is ID_OB to distinguish whether object_handle_update need to
be called for node->ob.

This saves iterating via scene's bases when preparing threaded
update. This also will very much likely update objects which are
not in the scene base are used in dupli groups.

So now objects form dupli_groups are likely already properly updated
white traversing the DAG with threaded update and special hacks
are needed from main thread to update objects from dupli_groups
which was added in previous commit.

However, kept this hack for a while, need some more thoughts
and investigation.

Modified Paths:
--------------
    branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/depsgraph.c
    branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/scene.c

Modified: branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/depsgraph.c
===================================================================
--- branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/depsgraph.c	2013-07-03 12:22:46 UTC (rev 57956)
+++ branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/depsgraph.c	2013-07-03 12:32:17 UTC (rev 57957)
@@ -2681,31 +2681,6 @@
 			}
 		}
 	}
-
-	/* A bit tricky, tasks are operating with nodes, which is much
-	 * easier from tracking dependnecies point of view, and also
-	 * makes it possible to do partial object objects.
-	 *
-	 * However, currently the only way we're performing update is
-	 * calling object_handle_update for objects which are ready,
-	 * which also updates object data.
-	 *
-	 * And for this we need to know whether node represents object
-	 * or not.
-	 *
-	 * And we mark all the nodes which represents objects as
-	 * white color, All other nodes are staying gray.
-	 */
-	for (node = scene->theDag->DagNode.first; node; node = node->next) {
-		Base *base = scene->base.first;
-		node->color = DAG_GRAY;
-		while (base && base->object != node->ob) {
-			base = base->next;
-		}
-		if (base) {
-			node->color = DAG_WHITE;
-		}
-	}
 }
 
 /* Call functor for every node in the graph which is ready for
@@ -2732,7 +2707,7 @@
 {
 	DagNode *node = node_v;
 
-	if (node->color == DAG_WHITE) {
+	if (node->type == ID_OB) {
 		return node->ob;
 	}
 

Modified: branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/scene.c
===================================================================
--- branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/scene.c	2013-07-03 12:22:46 UTC (rev 57956)
+++ branches/soc-2013-depsgraph_mt/source/blender/blenkernel/intern/scene.c	2013-07-03 12:32:17 UTC (rev 57957)
@@ -1327,6 +1327,15 @@
 	 * This is solvable with local group dependency graph or expanding
 	 * current dependency graph to be aware of dependencies inside
 	 * groups.
+	 *
+	 * P.S. Objects from the dup_group are very much likely in scene's
+	 *      dependency graph and were alreayd updated in threaded tasks
+	 *      scheduler already.
+	 *
+	 *      So objects from the dupli_groups are likely don't have
+	 *      OB_RECALC_ALL flag here, but it seems they still do have
+	 *      non-zero recalc flags, and here we make sure things are
+	 *      100% by calling BKE_group_handle_recalc_and_update.
 	 */
 	{
 		Base *base;