How to optimize performance for a particularly intensive UMG widget?

International
, , , ,
1

So, I’m currently working on a project where I need to have a developer tool that shows buttons that control which tiles of this grid are selected.
(Image 1)

image
image1479×918 115 KB

I’d say I did a pretty good job on that, however there was quite an unexpected performance problem… (One that we didn’t foresee)

Task Requirements:
You see the grid size can be a maximum of 35x35 (Which is a Requirement), which is 1225 buttons that can show up on this “Editor Utility Widget”…
With the use of scale boxes, and scroll boxes, and a uniform grid, I’m able to create these 1225 buttons in the way you see in.
(Image 2)
image

And here is the button: (Image 3)
image

As for the code inside of the button… I’ve made sure that nothing uses any ticks.
So each button on spawn is entirely event-based.
So while they appear on screen, essentially nothing in their code is firing.

Here’s what I did:
I followed possible solutions from this UMG Documentation at:
Optimization Guidelines for UMG in Unreal Engine | Unreal Engine 5.0 Documentation

  • I’ve discovered that I had used a bit too many nested scale boxes and horizontal/vertical boxes, so I compromised and decreased them.

  • I’ve also discovered that I had the problem “Use Event-Driven Updates Instead of Bound Attributes” mentioned in the link, and also fixed it.

At this very moment and given the requirements of my task, and with my high-spec PC…
I’m able to get 30 FPS with the 35x35 requirement.
(Image 4)

image
image1216×353 58.8 KB

And 39 FPS with the 35x35 Requirement IF I remove the root scalebox. (Found at Image 2)

So… my question is, what else could I do to show 1225 buttons on the screen, have them scaled correctly, have an option to scroll, and make them uniformly spread in a grid.
Which I haven’t already done?

Perhaps there’s a way to show how much processing this “Editor Utility Widget” is using?
Perhaps I don’t need to do that if I can immediately fix an obvious problem that I may not have realized?

So yeah… I’d appreciate the help.

2

Hey there @2010wolf! Welcome back to the community! I originally came to the post to ask if you had this entirely running event driven but it looks like you already have so that’s great! UI isn’t my strong suit, but optimization is in my wheelhouse, and one of the best tools in my toolbox that are applicable to every scenario/system is contextualization. How imperative to operation is it to have all of the buttons visible at once? Is there any way an abstracted version would make more sense (performance wise)? What are the relevance of the lit/unlit buttons?

1 Like
3

For such a large number of buttons it is better to use a List View or even a Tile View (аs stated in the documentation “a ListView that presents the contents as a set of tiles all uniformly sized”). Such widgets use virtualization of displayed content (draw only what is in the visible area) but require more effort to configure them properly.

1 Like
4

Hey, thanks a lot for the reply.
When the buttons are to be visible to the developer, a big portion must appear all at the same time, and because there can be 1225 buttons max, that’s the reason I used a scrollbox.

So, not all of them have to appear on the same time because with a bigger number they can be very small, which wouldn’t look good.
So, a requirement would be a big portion of the buttons (let’s say 6 or more rows) should appear at the same time.

Lit buttons are selected buttons. (Or hovered buttons)
Unlit buttons are unselected buttons.

The developer Selects buttons, and then he can store the selected buttons numbers when he hits “Save”.
This stored data is used in another system.

5

Hi @Neyl_S , Thanks for the reply!
I’ve checked out what a “Tile View” is, and I think that’s what I’m looking for.
I’ll check my options first before I do this, because I’d have to rewrite parts of the system.

Thanks a lot for the input!
I’ll notify you if I do implement this and what are the results.

6

Well… it doesn’t seem I can edit the post…
For anyone reading this… I haven’t yet implemented anything because I’m still waiting for all the feedback/ideas I can get, so I’d then explore all of them and then check which one is the best.

At the moment the “Tile View” seems like a very good candidate option, but I’m waiting to see what other options people might suggest.

7

That is definitely a tough one, if we can’t abstract the menu at all, it’s likely best to try to simplify the display a bit to see how much we can reduce it. Tile view like Neyl suggested is one way to pull it off, otherwise hiding the buttons contextually would be the next step, but if they all need to remain visible for the use case it’s less useful.

1 Like
8

Have you looked into wrapping everything in an Invalidation Box? (Under Optimization in UMG Designer)

You may also (if you have advanced skills), look into what they did at Rocksteady games - https://www.youtube.com/watch?v=OyY3OYbNK7s

I am late to this topic, but might be worth something to someone coming across this topic

1 Like
9

I’d imagine the number of canvas panels you are spawning from the button having one in it’s root is causing a performance problem. Kill the canvas panel for a size box and see how you get on.