It’s probably the change we made to Slate to condense the layout, tick and paint pass. Previously we performed a layout and tick pass, then another full layout and paint pass. Doing 2 layout passes, and ticking invisible widgets was prohibitively expensive. Now we do a single pre-pass (which caches widget desired size info), then recursive tick/layout/paint through the visible widget hierarchy.
Now, by the time you get the Tick, the slate pre-pass has already occurred and it will use that info for painting. If you’re going to change the hierarchy of a widget inside of Tick, you should call ForceLayoutPrepass on the ScrollBox after adding the children.
As a side note though - it’s not a good idea to recreate widgets every frame. It’s not free, and you’re generating a lot of garbage that will need to eventually be collected. Though it is more work, you’d probably be better off only rebuilding the widgets when the scoreboard needs to be updated. Rank changes, or the player list changes, rebuild away.
Nick thank you for the comprehensive response, it sounds like those changes are the likely culprit.
The EventTick only seems to be called when the scoreboard is being shown by the player so I guess I am ok with a quick and dirty solution using ForceLayoutPrepass which works for now.
Ideally ScrollBox could mature to use a pool of widgets somewhat similar to how UITableView works with UITableViewCells in Apple’s Cocoa Touch framework. Do you think we could see the ability to set a custom widget and a pool count on a ScrollBox? Or do you think that is too niche of an application?
We have controls that are similar, SListView and STableView. The plan is to finish wrapping them for UMG, but they’re non-trivial and there has always been a higher priority thing