Hopefully this is interesting/helpful to someone.
This came about through an investigation in another thread.
Video attached for reference.
When looking at tooltips, there seems to be quite a large increase in "game render preparation" for entities where there is a moving/changing progress bar (or maybe changing text?). Game render preparation time increases by about 500-600% if the bar is changing. i.e. if the solar panel is somewhere between "full day" and "full night", the game render preparation goes from 0.2ms to 1.0ms
This is very easy to see with solar panels and accumulators. The "game preparation time" when looking at the tooltip for an accumulator increases by 500% if the accumulator is charging/discharging.
The same for solar panels during their transition point between generating full power during day and none during night. The "game preparation time" jumps if that bar is moving.
The difference in "game preparation time" is about 1ms, which seems to be quite a lot?
This may also be the case for entities such as steam turbines, and maybe pipes and other entities depending on what is going on?
[2.0.15] Surprising performance cost for bars moving
Re: [2.0.15] Surprising performance cost for bars moving
Having looked into this a bit more this seems to affect any "progress bar" on a tooltip that isn't either full or empty e.g. fluid wagons, fluid tanks, pipes, etc.
Also radars! (sector scanning progress)
To put this in perspective, looking at the following chaos on Vulcanus, mousing over a radar with a "sector scanning progress" makes the "render preparation time" increase by about 50%. Same with a pipe or any entity with a partial progress bar.
Also radars! (sector scanning progress)
To put this in perspective, looking at the following chaos on Vulcanus, mousing over a radar with a "sector scanning progress" makes the "render preparation time" increase by about 50%. Same with a pipe or any entity with a partial progress bar.
- 20241118170730_1.jpg (1.58 MiB) Viewed 435 times
- 20241118170735_1.jpg (1.66 MiB) Viewed 435 times
Re: [2.0.15] Surprising performance cost for bars moving
Thanks for the report. This is a known thing - when the tooltip is changing it's remoted and re-created each time it changes. Because the progress bar is changing each tick it's re-created each tick.
If you want to get ahold of me I'm almost always on Discord.
Re: [2.0.15] Surprising performance cost for bars moving
Thanks for the response!
So from the looks of the increase in render preparation time it's recreating the entire tooltip graphic for each frame, even if only a few pixels on the tooltip have changed?
This does have an impact in multiplayer games where one of the computers is close to the edge of falling behind the server. 1ms for render prep is about 6% of the time the game has to keep to 60FPS in multiplayer?
From what another poster has said the render preparation cannot run simultaneously with the game logic, so perhaps an option to add a delay to how often tooltips are updated might be a performance option?
An extra 1ms for the game logic to run would be very handy as factories get bigger!
So from the looks of the increase in render preparation time it's recreating the entire tooltip graphic for each frame, even if only a few pixels on the tooltip have changed?
This does have an impact in multiplayer games where one of the computers is close to the edge of falling behind the server. 1ms for render prep is about 6% of the time the game has to keep to 60FPS in multiplayer?
From what another poster has said the render preparation cannot run simultaneously with the game logic, so perhaps an option to add a delay to how often tooltips are updated might be a performance option?
An extra 1ms for the game logic to run would be very handy as factories get bigger!