We currently facing a long delay each time we try to switch into Playmode in Unity. After some editor profiling we could pinpoint FlowCanvas as a possible source of this delay (about 10-15 seconds). We are currently using an older Version of FlowCanvas (2.5.5) as we did some smaller adaptation for our game and switching to a newer version is not a simple task for us. So our questions are: Is the current version (2.7.0) faster than 2.5.5 when switching to playmode (serializing/deserializing data)? Has there been any optimization in this direction?
The delay is most than probably due to an “editor only” feature which allows the hierarchy icons to show the active state of each GraphOwner (white/yellow colors + play/pause icons).
The delay in this case is happening due to the hierarchy panel repainting whenever the active state of a GraphOwner is changing.
This “feature” can be disabled from within the “Prefs” dropdown in the node editor. The option is named “Highlight Active In Hierarchy”.
If the version you are using does not have this option, then you can manually disable this by changing a few lines in the source code in case you can’t upgrade. Simply open GraphOwnerInspector.cs and completely remove or comment out the following line of code at line #18: GraphOwner.onOwnerBehaviourStateChange += delegate { EditorApplication.RepaintHierarchyWindow(); };
Let me know if that works for you and if that was indeed the cause of the delay (which has been reported before to be the case btw).
Thanks.
Hi!
Thanks for your reply. Unfortunately, we don’t have the option in UI nor does the GraphOwnerInspector.cs contain the line you described. We even searched the GraphOwner.cs (and the entire project) for the onOwnerBehaviourStateChange event but there is nothing there. Maybe the older version 2.5.5 is the problem?
I am sorry for the late reply, but there was a problem with the forums lately. My previous reply was deleted.
Since you don’t have that kind of code in your version, then it’s certainly something else that is causing the performance hit.
Here are two possible causes:
1) Using a lot of Macros in your flowscripts.
2) Initializing a lot of flowScripts at the same frame. For example instantiating a lot of flowScript controller based gameobjects in the same frame.
Hi,
we currently use about 50 macros in our project. Mainly, to better organize our Flowcharts into sub parts for better readablity. Is that to much? Is there another(more performant) way to enacapsulate and hide certain parts of the flow chart? We could pull out all elements of the macros and combine it into a single large chart but it would become very hard to understand and to maintain…
Another way to group functionality is by creating the new in latest version “Custom Functions”. Custom functions are similar to macros, with the big difference being that the implementation is not on a separate asset, but rather part of the same flowscript. So apparently if re-usability even outside of the flowscript in which the custom function is designed is required, then Macros are indeed the way to go.
The problem with a lot of macros, is that since each Macro is a separate asset, each of those macros are instantiated, deserialized and initialized when a flowscript that use those macros is initialized as well.
I will certainly need to improve macros initialization though. I’ve tried in the past without much success, since json deserialization in itself creates allocations, even though I have greatly optimized the json serializer used. I will give it another go though.
Thank you for your reply. We will try then to update to the latest version and use the “custom functions” feature as you mentioned. We keep you posted whether or not this could solve our problem …