Opened 5 years ago

Closed 5 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)

screen00064.jpg (1.5 MB ) - added by beherith 5 years ago.

Download all attachments as: .zip

Change History (18)

by beherith, 5 years ago

Attachment: screen00064.jpg added

comment:1 by beherith, 5 years ago

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.

comment:2 by Bluestone, 5 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.

Last edited 5 years ago by Bluestone (previous) (diff)

comment:3 by Bluestone, 5 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:4 by Bluestone, 5 years ago

[4628]

leaving open since garbage issue is still present

comment:5 by Bluestone, 5 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 Bluestone, 5 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 Bluestone, 5 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.

Last edited 5 years ago by Bluestone (previous) (diff)

comment:8 by Bluestone, 5 years ago

Resolution: fixed
Status: newclosed

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

comment:9 by beherith, 5 years ago

Resolution: fixed
Status: closedreopened

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 Bluestone, 5 years ago

Owner: set to Bluestone
Status: reopenednew

comment:11 by beherith, 5 years ago

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 :(

comment:12 by beherith, 5 years ago

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

comment:13 by Bluestone, 5 years ago

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

comment:14 by Bluestone, 5 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.

Last edited 5 years ago by Bluestone (previous) (diff)

comment:15 by beherith, 5 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 Bluestone, 5 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.)

Last edited 5 years ago by Bluestone (previous) (diff)

comment:17 by Bluestone, 5 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.