SlateIM FSlateIMTableView can get stuck in an infinite loop of rebuilding itself if it has enough child elements

Development Pipeline & Plugins
, ,
1

The callstack includes private code paths. Hopefully the information above is enough. Reach out if you need more details

[Attachment Removed]

2

Steps to Reproduce
A colleague has found an issue in a change made to SImTableView.cpp ([SlateIM: Fix case where child rows would not get removed when no long… · EpicGames/UnrealEngine[Content removed] with the exception of the very first SlateIM::BeginTableRowChildren now no longer displaying an expander arrow (but the functionality still works if you double click the entry). Any ideas as to why we are getting stuck in an infinite loop here and what we can do to fix it?

[Attachment Removed]

3

Sounds good, and apologies that the sizing change didn’t work. It’s likely some combination of size changes that get it stuck in the RequestRebuild loop, we’ll keep an eye out on our end as well in case we can get a reliable repro.

[Attachment Removed]

4

Hi,

I haven’t had any luck reproducing this in the SlateIM Test Suite (I tried adding many more entries to the tree example since the children rows seem to be a factor), but we have made a number of changes recently that might improve things here. Specifically, you might try grabbing CL#50255193, as that addresses a bit of jitter that could be the underlying cause (since you’re seeing the scroll bar flicker in). Do you know if the loop is caused by very large tables, or very deeply nested tables?

One possible explanation that I can imagine would be a hysteresis scenario where the scrollbar appears, cutting off a deeply nested child that was barely on screen horizontally. We should still be reserving room for those off-screen rows, but I’m seeing some size changing related to text widgets trying to autowrap so that could be causing things to shift around and triggering more rebuilds. Hopefully that fix will resolve it, but if not then a screenshot of the table (even if it’s redacted, just looking for the shape of it really) might help us track down a repro case. Alternatively, if you can manage to get the loop to trigger in the test suite then that would be perfect.

Best,

Cody

[Attachment Removed]

5

Hi,

Thank you for looking into this. We have tried integrating the change, but it seems like that area has changed noticeably since the last release. We changed the one case where it made sense, but we still get the issue. I attached a blurred video of the issue. My colleague mentioned it happens with a large table (many entries) and nested, after around 3 levels deep of BeginTableRowChildren.

Let me know if that helps narrow down the issue.

Best,

Jon Ander

[Attachment Removed]

6

Ah, that’s super helpful. This looks like a Slate hysteresis issue that has been around for some time (you’ll see it in the editor occasionally), the workaround is typically to resize the window when it happens in the editor. For SlateIM, a good workaround is to maximize the size of table so that it can’t get into that state of trying to resize:

HAlign(HAlign_Fill);
VAlign(VAlign_Fill);
Fill();

You may need that for the table itself as well as any container above it in the hierarchy, hopefully that should be enough to make it behave.

Best,

Cody

[Attachment Removed]

7

Thank you Cody. That didn’t solve it for us. My colleague keeps pointing at “RequestRebuild”. He also mentioned it stops while you select the window for resizing and goes back to the issue once released.

We don’t have time right now to find a repro, so we will stick with our suggested fix from the initial post. If we come up with more details, we will let you know.

[Attachment Removed]