Switch Playmode Lag

Forums › 💬 FlowCanvas › ⚙️ Support › Switch Playmode Lag

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • March 3, 2018 at 7:40 pm #21976
    tracecat
    Participant

      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?

      March 7, 2018 at 5:12 pm #21983
      Gavalakis
      Keymaster

        Hello,

        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”.
        [attachment file=”HighlightActive.png”]

        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.

        March 8, 2018 at 1:24 am #21982
        tracecat
        Participant

          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?

          March 15, 2018 at 5:47 am #21981
          Gavalakis
          Keymaster

            Hello,

            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.

            Could either of the above be the case for you?

            Please let me know.
            Thank you.

            March 20, 2018 at 1:23 pm #21980
            tracecat
            Participant

              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…

              March 20, 2018 at 4:55 pm #21979
              Gavalakis
              Keymaster

                Hello,

                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!

                March 21, 2018 at 3:45 pm #21978
                tracecat
                Participant

                  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 …

                  March 23, 2018 at 9:54 pm #21977
                  Gavalakis
                  Keymaster

                    Thanks for the follow up.

                  • Author
                    Posts
                  Viewing 8 posts - 1 through 8 (of 8 total)
                  • You must be logged in to reply to this topic.