Performance considerations

The Semantic Color Palette update system is designed for robustness, simplicity and coherent behaviour between in-editor and runtime usage.

While speed has not been its main design focus, the performances impact of the system should be non-significant for most use cases.

We made sure that no garbage is constantly generated and that the amount of data copied around through the API is kept reasonable.

That said, if you have a very complex scene and you want to squeeze out all the possible performances, you can go the extra mile and disable the colorers and the providers components when you don't need color updates.

Note

Thanks to the architecture of the system, if you disable any colorer or provider, change some palette colors when they're disabled, and then enable them back, they will perform an update if needed, anyway.

Sometimes, having the system running only in the Unity editor might be enough: if you have no color palette changes at runtime, that's all you need. If this is your scenario, just add on any node of your scene the included script SCP_EditModeOnly.cs (is in the RuntimeManagement folder) and it will take care of automatically disabling the system when you run the application, and, if running in Unity, re-enabling it when you stop it.

Additionally, in Unity, you can use disable/enable this script (using the execution checkbox in its inspector panel) to change at any time the state of the system:

• checked: system disabled in play mode
• unchecked: system enabled in play mode

Note

This might seem a little "backwards", but it is the most straightforward and clean way to implement the desired logic. Having the SCP_EditModeOnly script disabled (unchecked) is like not having it in the scene, and so the system will work in both edit and play mode. Enabling it, it will disable the Semantic Color Palette behaviours when execution start (after hitting play), and when it stops it will re-enable them (so that edit mode will work as espected).