The purpose of this diff is to use object semantics using class syntax for the
FPS/realtime/gametime/ceasefiretime counters shown in the top right corner of the screen in the course of #5387 and
to make the gui/common/ code agnostic of the session code.
The gui/common/functions_global_object.js file hardcodes the name of a session function and calls that if it exists.
Prior to rP19268 there were even more references including g_SimState in gui/common/.
rP16624 had hadded the ceasefire hotkey refernce without inserting them in default.cfg, so basically noone knew about the hotkey, fixed here.
Another small odditiy removed here are the objects in global.xml that on first read appear like they would be the counter objects.
But they are not. Despite having the type "text", they never show any text, the style is unused too. The objects only
exist to have something to attach the hotkey to, thus can be superseded by Engine.SetGlobalHotkey from D2260/rP22851.
The advantages of the class hierarchy are that one can perform some tiny performance tunings and to split the different counters into different files,
allowing to read, comprehend, insert, delete or modify one without having to modify or read the others.
The (mostly negligible but relevant in principle) performance leverage is that one can
- avoid constructing a sprintf JS object every call and can reuse a once allocated one,
- avoid doing Engine GetConfig calls every call
To achieve these benefits:
- ceasefire message subscription following style of rP23076/D2378
- move of configchange message from rP23091/D2389 from session/ to global/, fired from within options page and mainmenu when closing the options page
In order to avoid quadduplication of the overlaycounters logic,
this is the first patch that uses the class inheritance using the extends keyword.
Why the patch isn't ideal:
- The ConfigChange message should still be sent from C++, not JS
- g_OverlayCounterManager needs to be assigned in onLoad in XML, since the XML file wasnt loaded yet when the JS file is loaded and since it can't insert itself into JS and since we dont want JS code in global scope that isnt a class, function or variable definition.
- This still requires one function call per counter and requires traversing the prototype chain. So in this regard slower than the mashing all counters in two functions.
- More complexity. Not updating everything at all all the time means there is more possibility to get the wrong state in some circumstance somewhere.
- The order in how the counters appear cannot be determined in a way that is compatible with the objective of the patch to allow insertion and removal of one ceasefire without changing the manager or requiring knowledge of the other overlay counters. One would have to use an array like ["counterName2", "counterName1", ...] to specify an order, or use arbitrary intransparent priority numbers, or remove the ability to use a specific order. But the latter would be wrong, people expect that the ceasefire counter appears last. Since this problem is not solveable with the current ideas, I used the path of least ugliness and chose the classname, and thus had to use RemainingCeasefire instead of Ceasefire in order to change the, order.
Aside from that, there is also a much more effective and simple performance boost in this diff
- Update the counter 4 times per second, not once per frame
- Don't resize if the number of lines didn't change (happens very rarely)