-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Add stress test for many ui elements #5253
Conversation
This is not testing much of the UI, just spawning buttons:
|
I want to keep this test focused. The original version of this test in ui-navigation did indeed only exist to test the focus system (well, my own). However, the ui rendering code is just too slow for even the slowest and most naive mouse picking algorithm to contribute in any meaningful way to the global run time of the app. You are indeed right. There is no hierarchy or change to layout, yet the test is still staggeringly slow I get 2FPS in release mode. Given the layout is static, this should be smooth as butter. Why is it so slow? Well, now we have a test to help us answer that question! Here are the most prominent tracing spans in tracy:
This stress test was already helpful, it helped me test if #5252 made the base case slower. |
Ha I didn't expect just buttons to be that slow... for reference:
So even for similar number of elements, UI is slower |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add the FrameTimeDiagnosticsPlugin
and LogDiagnosticsPlugin
plugins like in other stress tests?
In this example I don't think it's needed to display the ui element count as there isn't culling
Most of the improvements that were made to the sprite systems were not made for the ui, so it should be "easy" to improve. This example will help for that. After that, we could add complexity to test other things |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on board. We should add a deeply nested layout stress test later, but that can wait.
bors r+ |
# Objective Bevy need a way to benchmark UI rendering code, this PR adds a stress test that spawns a lot of buttons. ## Solution - Add the `many_buttons` stress test. --- ## Changelog - Add the `many_buttons` stress test.
Pull request successfully merged into main. Build succeeded: |
# Objective Bevy need a way to benchmark UI rendering code, this PR adds a stress test that spawns a lot of buttons. ## Solution - Add the `many_buttons` stress test. --- ## Changelog - Add the `many_buttons` stress test.
# Objective Bevy need a way to benchmark UI rendering code, this PR adds a stress test that spawns a lot of buttons. ## Solution - Add the `many_buttons` stress test. --- ## Changelog - Add the `many_buttons` stress test.
# Objective Bevy need a way to benchmark UI rendering code, this PR adds a stress test that spawns a lot of buttons. ## Solution - Add the `many_buttons` stress test. --- ## Changelog - Add the `many_buttons` stress test.
Objective
Bevy need a way to benchmark UI rendering code,
this PR adds a stress test that spawns a lot of buttons.
Solution
many_buttons
stress test.Changelog
many_buttons
stress test.