Opened 7 years ago
Closed 7 years ago
#968 closed defect (fixed)
Selection menu presents a large load each time a command is issued
Reported by: | beherith | Owned by: | Bluestone |
---|---|---|---|
Priority: | minor | Milestone: | BAR Beta release |
Component: | BAR | Version: | |
Keywords: | Cc: |
Description
With the profiling view active, it can be seen (and also felt) that whenever a command is given, there is a perceptible stutter.
To reproduce, just select any single unit, and drag a move command (so that it is given a list of waypoints. Profiling shows selection menu load through the roof, and the alt+b /debug view also shows large chunks of time spent in unsynced lua.
The screenshot has the lua profiler value highlighted, as well as large chunks of time spent in Unsynced visible.
Attachments (1)
Change History (18)
by , 7 years ago
Attachment: | screen00064.jpg added |
---|
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Using lots lua ram is the cached images and is not related (or a problem, afaik). We are far below the lua mem limit.
sMenu refreshes each time a command is given. This is probably why it has a high GC load when you right-click-drag to spam commands at it. I can't see a sensible way to avoid this atm.
comment:3 by , 7 years ago
n2s, sel menu and main menu between them cause 9% GC load, something must be wrong there. chili framework (with no other widgets running -> 0 controls) causes no GC time.
comment:5 by , 7 years ago
Seems like garbage collection issue is a Chili issue, unrelated to images and affecting all Chili controls equally.
local controls = {} for n=1,2000 do controls[n] = Chili.Label:New{} end
reproduces the exact same effect (and is approximately how many control sMenu uses).
comment:6 by , 7 years ago
Also, the (relatively high) mem usage of sMenu comes from presence of many controls, rather than anything related to images
comment:7 by , 7 years ago
As a result, the GC issue is not fixable, and seems to be inteded behaviour of Chili.
The GC load can be maybe reduced by 1/3 by baking all buildpic additions (raindrop, etc) onto the images, but this is inflexible due to semi-broken icon generator and won't look good either.
comment:8 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The original ticket is basically fixed, the GC issue is cantfix.
comment:9 by , 7 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
The GC issue is fixed in 101, but some of the original remains. I have tracked down much of the load being that state and order commands are recreated every time, instead of being cached like the unit icons are.
comment:10 by , 7 years ago
Owner: | set to |
---|---|
Status: | reopened → new |
comment:11 by , 7 years ago
In [4706] a the state and order buttons are cached. There are two outstanding issues left:
- The STOCKPILE count is no longer displayed, as the buttons are cached, and I couldnt immediately figure out how to only update the label of the stockpile button.
- Whenever a buildmenu item is clicked to queue something to be build, requireUpdate fires twice, so there are two updates :(
comment:14 by , 7 years ago
The "double" updates should be mostly fixed by [4711]. Unfortunately, this means we have to hack it with [4713] in the case of CMD.PASSIVE because of https://springrts.com/phpbb/viewtopic.php?f=23&t=34380.
I've fixed the stockpile label [4714]. Close if all good now.
comment:15 by , 7 years ago
Wow, insane progress Bluestone, everything is buttery smooth now, I'm truly impressed on how much this (extremely annoying to me) bug has been mitigated!
Just one thing though, can the states be selectively updated only if a unitstate is changed, because with all the optizimations, that seems to have been culled :D
comment:16 by , 7 years ago
Decoupling the update mechanisms for order,state,build should work fine, I'll look at it later. (I don't think it was culled, afaik it was never there.)
comment:17 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Actually better not, since all the information comes from a single GetActiveCmdDescs call.
Just as a side note, bgu_sMenu also allocates more than half of all the used Lua RAM, and is actually causing the garbage collector to produce a very significant load (GC is pink on the profiler). Disabling sMenu drops the Lua ram use in half, and more than halves the GC load as well. Also, not only the orange, unsynced loads are huge after a command is issued, the next drawframe (green) is also much longer after a command is issued.