Selection menu presents a large load each time a command is issued

[beherith]

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.

[beherith]

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.

[Bluestone]

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.

[Bluestone]

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.

[Bluestone]

[4628]

leaving open since garbage issue is still present

[Bluestone]

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).

[Bluestone]

Also, the (relatively high) mem usage of sMenu comes from presence of many controls, rather than anything related to images

[Bluestone]

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.

[Bluestone]

The original ticket is basically fixed, the GC issue is cantfix.

[beherith]

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.

[beherith]

In [4706] a the state and order buttons are cached. There are two outstanding issues left:

1. 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.
2. Whenever a buildmenu item is clicked to queue something to be build, requireUpdate fires twice, so there are two updates :(

[beherith]

Goddamit i broke right clicking to dequeue units in factory :(

[Bluestone]

It was me who broke right click to dequeue, fixed it [4710]

[Bluestone]

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.

[beherith]

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

[Bluestone]

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.)

[Bluestone]

Actually better not, since all the information comes from a single GetActiveCmdDescs call.