QORPOUnreal UMG invalidation: measure a menu in two states
Compare an idle Unreal Engine menu with the same menu during a real interaction before changing its invalidation setup. Measure what stays stable, what changes and how much Slate work each state produces. Caching can reduce repeated work for stable widgets. An interaction that repeatedly changes a large subtree can still be expensive. The useful question is which widgets have to recalculate when the player performs one action.
What does invalidation do in UMG?
Invalidation lets Slate reuse cached work until a widget changes in a way that requires it to be recalculated or repainted. An inventory frame that remains on screen with the same layout may be a candidate. A selection indicator or progress display that changes frequently has a different workload. Epic documents both local approaches and global invalidation. Check which one your project uses before choosing a widget to change. Epic's guide to invalidation in Slate and UMG.
The cost of an update also depends on what changed. A visual change can be smaller than a layout change. Adding and removing children can require the widget tree to do more work. Keep those interactions separate when you record them. If you scroll, rebuild the list and open a panel in the same capture, a timing spike cannot tell you which action caused it.
Establish an idle reference
Use a specific menu with a repeatable starting state. Record the build, device, screen resolution and item count. Open the menu and wait for its entrance animation or initial data load to finish. Capture a short steady window with no input. If the menu has a timer or a moving highlight, note that in your capture. Idle in this exercise means the player is not touching the controls. The UI may still be updating.
Capture a comparable interval after your change. Keep the same menu, device, scale and data. The QORPO guide to recording render resolution gives a related example of how changed settings can confuse a comparison. If a background task ran in one capture, capture another clean interval before drawing a conclusion.
Model example: change one selection
Imagine a six-item equipment menu. The outer frame, category title and help text stay fixed. Moving the selection one row updates a highlight and a details panel. Record that single move in the original version. Then test a version where the stable frame is separated from the region that changes. Use the same six items and the same input. Measure both the steady window and the moment the selection changes.
Look at the display as well as the trace. Confirm that the correct item description appears immediately, keyboard focus is still visible and the right sound plays. Test a second action that changes the list length, such as filtering to a smaller group. This exercises a different update path from moving a highlight through an existing list.
If the idle trace improves but selection becomes noticeably slower, keep the two observations separate. The result suggests a tradeoff that needs another focused measurement. A single average across both states can hide an expensive interaction. Record the range and keep the interaction trace beside the idle sample so another reviewer can check the difference.
Where should you start if work repeats every frame?
Identify the widget that changes before moving the entire menu into a new cache. Look for a constantly updating value, a binding doing work repeatedly or an animation that moves more of the tree than intended. Check whether the update has to happen on every frame and whether it belongs inside the stable region. Epic's UMG optimization guidance describes how frequent updates and invalidation interact.
Treat changes to input and focus as part of the check. Open, close and reopen the menu with the same control, then make sure the first action still works. The pause menu resume check and the studio guide to effective settings values offer complementary ways to record what actually changed.
Is there one setting that improves every menu?
Choose a scope based on the observed updates and the project's current invalidation configuration. A stable frame and a constantly changing display deserve separate measurements. The result should state what you tested and which interactions still need a closer look. You can read more practical development notes on the QORPO blog.