37 - Add Waaaghbar Timer that all plugins could use
What does the provided patch do?
Many addons could use a timer for things like xp/hr, renown/hr, gold/hr, etc. If each plugin handles the OnUpdate callback itself it would be wasteful since they could all use the same timer value. The timer should be able to be reset so all the plugins can start fresh if the user wants to.
Please provide any additional information below.
Note that I'll make a followup ticket to handle timer resets, each plugin using the timer should be able to register a callback to be notified when the timer resets so they can reset their variables if they need to.
| User | When | Change |
|---|---|---|
| Aerthan | Thu, 23 Oct 2008 14:15:15 | Create |
- #15
shockbeta Tue, 04 Nov 2008 00:37:22I know I kinda disregarded this at first passing, but after pushing out a clone and adding some features to it, this actually is starting to look appealing. I still stand that waaaghbar should not be in charge of keeping track of time, but the benefit you can gain by doing this can outweigh that. I did some testing over the past week since I've actualy been able to play and not work on addons, and the end result I get is no framerate hit whatsoever(if there is it's 1-2fps max) when all my addons are enabled an updating constantly. I run on full settings at 1680x1050. Only during times when I expect it to chug do I get any hiccup(large scale battles, taking keeps with everything cranked at highet quality, all these are tied to graphics not cpu cycles for me). Although I should keep in mind that not everyone has a system or luck like I have with playing and people may be hard pressed for cycles, or just not want things to update like I do. This is where the benefit of this idea shines.
Having waaaghbar keep track of time would actually allow you to set a true update speed per plugin as well as disable it from updating entirely, but still maintaining a time passed. Like some people I've read are experiencing UI lag in large battles, You could bind a function to disable all Updates in client or limit them to a slow speed, via a slash command so it could be macroed. That would allow you to be able to disable/enable updates on the fly across all plugins if they had a lower end system or just had ui lag.
- #14
Aerthan Sun, 26 Oct 2008 15:00:11I agree with the previous two comments, and yes Elder a plugin that showed xp/hr directly on the waaaghbar could definitely use something like the ace3 module for updates.
- #13
shockbeta Sat, 25 Oct 2008 00:14:04The funny part is this could all be avoided if mythic would of exposed a method for getting app time by a function call... I still can't believe they didn't expose a GetTimeSeconds(), SystemData.Time.TimeSeconds or something. They're obviously tracking it natively somewhere...
- #12
Elder82 Fri, 24 Oct 2008 19:54:03Ok, sorry: I did miss your point :)
In zTimeLib there is getEpoch (or similarly named), that gives the time passed from last ui (re)load, but of course you would like not to use such big a library to just get that. (I though you wanted to schedule function calls, not just to know time passed)
However I still do not agree with this suggestion: I don't think it's wgb duty to track the time. And if I have an addon that gives me xp/hr on whaaagbar I would like to see an up to date value without mouse overing it... :/
The word to the author, then: if he wants to include this, it is quite light weight, since there are no calls to other functions at every frame but just a counter update. :)
- #11
Aerthan Fri, 24 Oct 2008 13:58:40Elder you are missing the point entirely. For the plugins I'm talking about I don't want to be notified at .05 seconds, .1 seconds, 1 second, 10 seconds, or 100 seconds. I don't want to be notified at all. All I need to know is how much time has passed since I started running (or since the last reset) Ace3 doesn't do that, I could possibly use zTimeLib, store a timestamp when I start and calculate the delta time, this might be an option, but again I was hoping the original author might let us know if he had any plans.
- #10
Elder82 Fri, 24 Oct 2008 05:27:14sorry, but I think you misunderstood aceTimer source code: they say "Timers will not be fired more often than HZ-1 times per second.", where HZ is 11. So a timer can be fired every 0.1s, not 10s ^^
I think this is enough for most applications: if I need to get called more often, I register myself for OnUpdate ;)
So, imho, ace3 IS an option, together with zTimeLib :)
- #9
Aerthan Fri, 24 Oct 2008 05:16:22Ace3 is not an option, it only lets you do things like register to get called every 10 seconds.
Shock, not sure if you saw the implementation, but it's only one line so it's not much effort... :)
- #8
Elder82 Fri, 24 Oct 2008 03:07:16ops, I didn't know libTimer was abandoned :(
however as I said there where a couple timer libs :P
The other one, born because the author missed some functions in LibTimer, is called zTimeLib: I haven't studied it, but it allows function scheduling.
Also, in Ace3 there is AceTimer: it is yet another implementation of a scheduling library. This can be embedded in every addon, if needed, since it uses LibStub.
- #7
shockbeta Fri, 24 Oct 2008 00:51:35I'm about to head out of work so I'll make it short. 0.000075975s is all you'd lose if you let those 250 calls through from my rough testing. negligable. centralized timer is a good idea, but might not be robust enough for every plugin. Some people it would work out great, others not so much(I like my stuff updating constantly). There's pitfalls and drawbacks to either side. Both can lead to bottlenecks and frame rate hits. I'm just more apt to believe a script side method is more apt to frame rate hits then using the native method that was put in place originally(OnUpdate). I found libtimer page, it's been abandoned. Using a timer library would be nice, but can also cause problems. if too many events are registered to it it can lock you up on a frame trying to finish all it's calls, there could be code in place to prevent it, but the same can be said for native. I can go back and forth on pros and cons of either method so I'll just leave it at this...
The centralized timer is a nice idea, not sure if it's really worth the effort to make it, but it could turn out to be good.
- #6
Aerthan Thu, 23 Oct 2008 19:14:05Shock if you look at my patch, that's exactly how I coded it. It's commented out for now.
--for i = 1, getn(WaaaghBar.plugins do
-- d("Call OnTimerReset on "..WaaaghBar.plugins[i].name);
-- WaaaghBar.plugins[i].OnTimerReset();
--end
The main bar doesn't know anything about the implementation at all. As to your other point, if there are 10 addons that don't need to run 25 times a second, they just need to know how long they've been running, I'm not sure why you'd want them making 250 function calls a second rather than just the 25, but I didn't say they should be forced to use this. I know in other games it's these types of events that trigger constantly that end up slowing people down when you get enough of them.
Elder, where is LibTimer? I did a search of curse and didn't find it. For things like xp/hr I don't actually need updates every 10 seconds, I only calculate xp/hr on a mouseover. Again if LibTimer has an api for getting the current session length and the author doesn't mind being dependent on another addon I'd be fine with it.