healthbars eats perf when not drawing any bars

[Bluestone]

only applies when below its cutoff height (above a certain height it does nothing at all) - but /give all and zoom reasonably close & it eats perf but draws nothing

this is not related to [2454] (which has only small perf impact) although it does affect BAR too

[Floris]

I see nothing wrong or odd

the code responisble for the perf impact is:

line: 960

if (sec1>1/25) and ((cy-smoothheight)^2 < maxUnitDistance) then
    sec1 = 0
    visibleUnits = GetVisibleUnits(-1,nil,false)
end

[Bluestone]

Didn't read the code (yet) but calling Spring.GetVisibleUnits 25 times per sec (which i guess is what that code snippet does) is wrong and odd! Table creation/deletion in lua is an expensive operation, unfortunately.

[Bluestone]

After some testing, the time taken for the GetVisibleUnits call is not the major cause of this.

[Floris]

Old healthbars issue... I guess because it checks every unit for health, so drawing nothing doesnt even matter. Also dont forget with give all nukes and other units draw 'loading' bars aswell.

[Bluestone]

No - the checks for unit stats cost very little, even done at this magnitude. The cause is table deletion/regeneration.

[Floris]

turned config var 'featureReclaimVisibility' to false, so it wont loop all features at normal height, just on closeup.

this doesnt fix your description though

[Bluestone]

This issue is assigned to me (note that it's BA trunk, at least for now) and I haven't yet evaluated whether or not it's worth fixing.

Please concentrate on fixing the issues in your own code, which without really look, I would guess are due to making too many gl calls.

[Bluestone]

probably not worth the trouble