I was considering using it only in arena/battleground.
Moreover, I think I will add an option to disable farclip updates. Even if it is the parameter that have an heavy effect outdoors, it seems to create disk (and I guess memory) stress and thus to create some instability.
HunterZ touched on this already, but maybe changing the frequency of it's adjustments would be beneficial? Possibly slow down the rate at which it decides your settings need to be tweaked. I noticed that there are times where I'm standing still and it's twittering things higher and lower because of 1 - 3 fps differences. Possibly a configurable setting that it can check against for how long a person wants it to wait during an fps increase or decrease, before it moves anything. ie The user tells it to wait 5 seconds after fps decreases, before it decides to change settings.
I'm really tired, so i may have to re-write this later, to make more sense. >.>
Someone talked in the other thread about performance profiles, e.g. auto-selecting a performance profile based on where you are (battleground, arena, party instance, raid instance, major city). That may be an idea too though it might be a bit complex.
The LDB display that came with the version with an option pane doesn't appear to work at all with Broker2Fubar. Before that version, I would see a "Q:" or "Disabled" text on the bar (no icon) and I could hover that text for informations about what the addon was doing. With the latest version, there is nothing on the bar at all.
I'm using a lot of brokers with Broker2Fubar and it's the first time I have problem seeing stuff. It might be I guess that the other I have do not use text, value and sufix the same way.
[edit: my tests were with the latest beta taged release which was r5. I see that r7 is out and will test again.]
though I don't understand why ChocolateBar listens to *every* attributes.
I thought about registering only to the relevant attributes, but I realized I would need to register for almost all the attributes of the data spec. Making a total of 13 attributes to register for every DO (only enabled ones). So I'm not sure thats a good idea.
Besides that all that ChocolateBar does on the callback is a lookup for the attribute in the update function table.
I just thought I tell you about what I found while debugging a bug with ChocolateBar and DynPerf someone reported. (Was not relatet to this just a bug in ChocolateBar)