Nui Performance Considerations
Intro
These are a few notes that may help for menus that seem to take a very long time to load or freeze the client when opened, or avoiding that in the first place for larger, complex menus. Performance considerations usually won't matter for smaller to medium sized menus, but after a certain point in complexity cassowary will just bottom out under the load, causing client side freeze. That point where it hits it's limit will be different based on the speed of the computer running the client; players running older hardware will freeze up for longer.
Layout Considerations
NuiMargin still needs to be solved even if set to 0.0. Using default margins is faster in general.
NuiSpacers are expensive for cassowary to solve.
Nesting elements beyond 3-4 levels with an extreme amount of elements can become exponential to solve.
Functionality Considerations
Menus that use/need dynamic resizing may work fine in singleplayer, but may need that function disabled to be stable in multiplayer.
Using NuiSlider to adjust the size of NUI elements in realtime can easily cause a crash.
Some menus are made to load quicker by caching the JSON to a local variable on the module the first time it's opened and then requesting that data back when reopening the menu. This can backfire for really large/complex menus - the generated json can be so long that it takes longer to retrieve the info back from the server than to generate it again. Even when playing on a local network to the server. So there's a JSON size limit for this technique to be of any value. One way to keep it in manageable chunks is by breaking up the menu or dynamically loading elements in with NuiSetGroupLayout.
Summary
NUI is made to be dynamic and precise in it's layouts but currently isn't designed for large scale menus or interfaces that require a lot of real-time interaction. But that can still be achieved by keeping in mind what aspects can overload the cassowary solver when performance is a priority.
