SystemManager signals and GUI classes

One of the users noticed that outside of the Editor the UpdateSlot never gets connected to UpdateSignal of SystemManager.

It turned out this is by design.

Here’s the line from the Gui.cs with the accompanying comment:

// if in editor, monitor the GUI state (this is an optimization)
if (Application.isEditor)

That’s because inside the update slot I’m constantly comparing the old and the new values of public properties of the Gui class:

public void UpdateSlot(params object[] parameters)

    if (_visible != Visible)
        _visible = Visible;
        Stage.Visible = _visible;

    if (_clipContent != ClipContent)
        _clipContent = ClipContent;
        Stage.ClipContent = _clipContent;

    // ... etc...

Now, the reason for comparing values is that I couldn’t use setters – simply because they aren’t displayed in the inspector.

Gui class is just an adapter allowing users to access the Stage when in Editor (and saving these values with the scene). And this – naturally – has to be turned off in the production environment, because it is processor intensive.

Accessing Stage

You should actually never need to changing the Gui values in runtime. You should always consider accessing the Stage directly.

What the mentioned user actually did is he was overriding OnUpdate to run per-frame logic in a derived class.

Now, having the OnUpdate inside the Gui class was my mistake. It isn’t used from anywhere in the framework and starting from v1.12 this method won’t be available anymore.

This method obviously shouldn’t have the same status as OnInitialize, OnCreationComplete etc. because these are running “rarely”, meaning they execute once per scene (and you most probably want to process something inside these methods), while the Update signal is processor intensive (FPS times per frame).

Connect to the signal directly

So, if in need of using the Update signal inside your GUI class, you should connect to SystemManager’s UpdateSignal directly.

Furthermore, there’s really no need for processing anything FPS times per second inside of the GUI classes.

This is simply unnecessary, because the GUI is being rendered only when OnGUI method runs.


Component internals need to be updated just the moment before OnGUI kicks in. And this is by the time the PreRender signal fires.

eDriven.Gui also connects to mentioned PreRender slot and executes validation methods for each GUI component on screen (these methods are namely CommitProperties, UpdateSize and UpdateDisplayList).


You should always consider so your processing inside one of the validation methods, because they are being run at optimal time and just before rendering.

Alternatively, if in need for processing on update, you should connect to SystemManager’s UpdateSignal directly (don’t forget to disconnect later).

Posted in News