Your attitude isn't admirable either imo. Instead of working together to find a solution that works for people with crappy computers and demanding healers, you start accusing others of having no grasp of the subject? Sad..
The solution is to increase the update rate, not remove it. Simple as that. It has nothing to do with the rest of agUF, or bucketed events in general.
As far as I know, ag is planning on adding a slider so you can choose how fast you want things to update. I just can't stand to see someone claim to have all the answers and push to remove something all-together when it should be tweaked or fixed instead. Removeing it is just going to cause more harm that good for MANY MANY users.
About the buckets / bulk updates: in my opinion, unitframes should be written efficient enough to keep react on health changes instantly, not wait 0.2 seconds and *then* show me what happened.
You obviously have a very tiny grasp on the implecations of non-bucketed events, and don't understand why they came about in the first place. PerfectRaid was the first raid unit frame mod to use this techinque (in fact, PerfectRaid was initially created as a demonstration to prove that Bucketing events works, and works wonders.)
Sure, your computer can handle it, but how much KB/s increase do you have? How does that affect slower computers?
Why do you think so much lag is associated with raiding, UNIT_HEALTH is fired (a single event) for EVERY time someone takes damage, drinks a potion, is healed, etc... This also fires for any pets in the raid as well. Go profile Ag_UF (in a full 40-man raid) against CT_Raid or even the Blizzard default raid UI. You'll see a massive differance. A differance in how big your KB/s increasing rate is, which in turn affects your garbage collection (also know as the semi-seccond 'hiccups' that people associate with raiding). All this churn affects your FPS as well.
You want unit frames that are coded to efficently handle all this tidal wave of events? You already have it, its the entire reason that bucketed events are part of AceEvent, a core piece of Ace2.
You want frames that update instantly, faster than the human eye can even notice? Pull out your default raid frames or go install CT_Raid. Enjoy your lower FPS and increased KB/s while you're at it.
But please...don't try to dismiss 'facts' about things you know very little about.
Fine. Let me start by saying that I have read and understood the inner working of AceEvent. Please understand that buckets are nothing more than collectors for events, and it calls the handler with a table on a throttled rate instead of on every fired event.
The first obvious flaw: it waits for at least the specified time before it notifies the event handlers. With 0.2s, that is 1/7 Flash Heal of lag.
Secondly, you obviously don't have any idea how a garbage collected heap works. Using terms like KB/s makes that quite clear. In a nutshell, instead of forcing the programmer to keep track of changes (malloc and free, new and delete), in a garbage collected heap you can allocate objects (tables in lua) without paying attention, and the wasted space gets recycled someday. Note that variables on the stack have nothing to do with that and as a result, calling UpdateHealth 100000x times will not create a single byte of garbage with your current code - there is no table creation involved.
The third flaw is that you claim that you cannot see a 1/10th second delay. That is obviously false. Try playing wow on 10 fps, and wonder why every game aims for the magical number of 30 (rts, rpg) or 60-100+ (shooters). If something happens with my raid - I want to know that asap, and not 0.2 seconds later.
And finally, the bad performance associated with non bulk updates is caused by the event handler itself. It doesn't check the UnitID that triggered the event, so everytime *any* hp changes, all 40 bars updates itself. Rule #3: Profile (or just read, ffs) the code first, *then* optimize (fix, in this case).
I, and my guild is pretty happy with an instanly responding raid frame, without any *measurable* performance hit. Next time, do your homework first, and then start pointing fingers. And make sure you actually measure the cpu load / time spent / gcinfo() in those methods instead of pulling numbers out of thin air.
I have. I know you're not talking to me, but don't.. because I fully understand everything you're saying, and you're correct. I can't speak specifically to aguf, because I didn't write it.
The problem is, you run a high-level machine. High level machines can easily handle the full set of events, but lower level machines absolutely cannot. The whole point of the collectors (I hate the term buckets, not mine, btw) is to make the cost of the updates consistent whether you are in a raid, or out of a raid. Consider the following:
Register for UNIT_HEALTH and UNIT_MANA (leave focus, energy, rage out of it). Consider yourself in a 40 man raid.
In a span of 0.2 seconds, you can have a LOT of events firing (not even including UNIT_AURA). If you'd like to, you can check and see the rate of events that fire in the various fights (this has been optimized somewhat, and is certainly better than it used to be).
The fact remains, the best performance (defined as processing/memory and latency impact (i.e. how long it takes to perceive a change) outside a raid is to absolutely use the event system. The event system will give you instant response with minimal impact on the gameplay.
The best performance inside a raid is to update OnUpdate, in response to events. The frame rate for even medium level machines sits around 12 FPS during a raid. At 12 FPS you can respond to events within 0.1 seconds and get as instant response as you woudl with event handling. In this case, it could actually give you BETTER, due to the less overhead.
If you have a low end machine, in a raid, you shoudl unregister all events and update OnUpdate. Since you're only getting 2-3 FPS, updating each frame and ditching the event handlers gives you (literally) the best performance you can see. Since the graphics aren't being redrawn, updating the widgets is useless.
Its not a straightforward problem, but it is a straightforward solution.
EDIT: Also, ag_UnitFrames does CALL the handler once per unit regardless of whether or not the unit has been affected. It does NOT do anything (the first line of logic drops it out). The function call there is expensive, but shouldn't be the basis for the issues you're having. The reason for this is the OO design that ag is using, and the way he's handling the updates.
I personally iterate the table, and only update what's necessary.
EDIT #2: I _do_ algorithms. Its what I do. That being said, I 100% do not try to optimize code before its working, and without being fully educated. The whole reason for the slide you pasted is because too often peopel don't understand what optimization means. They can spend a day working on a path and optimizing it to absolute minimum cost, only to realize that it has no affect on their performance. You have to profile code, find your critical paths, and fully undertsand what and why everything is happening.
The concept of event collectors is fully applicable in wow, and very necessary in some cases to deal with the lower end clients. I stand by the use of them in general unit frames, however you have to know what you're doing, why you're doing it. The trunk versino of aguf is in development, and ag has said that. He's working on adding "features" and looking at some of the ways he handles things. People who don't like it can revert to a previous version while he works out his issues.
AG won't be back for two weeks, so suck up, revert, and deal. There's too much bullshit being flung in this thread from people who don't understand whats actually happening.
Works perfectly well for me. Somehow I doubt most healers would claim they need 43 frames updating faster than five times a second.
The problem is, there are handfull bosses in this game, where 0.2 delay on healing means death of tanks. Patchwerk is first on this list, twins and broodlord without best gear too.
The problem is, there are handfull bosses in this game, where 0.2 delay on healing means death of tanks. Patchwerk is first on this list, twins and broodlord without best gear too.
I use aguf as a raidhealer. I'd like to see a person who's fast enough to react in 0.2 seconds :)
The problem is, there are handfull bosses in this game, where 0.2 delay on healing means death of tanks. Patchwerk is first on this list, twins and broodlord without best gear too.
I use aguf as a raidhealer. I'd like to see a person who's fast enough to react in 0.2 seconds :)
0.2 sec is more than enough to throw renew/rejuv/shield/NS heal/Swiftmend/ to save tank on ubs/swordspec/crushing sentence in twins fight.
Patchwerk throw hatefull strike evey 1.2 sec for 7.5k. 0.2 sec matter, again.
If you do proactive healing (And you should), then 0.2s doesn't matter, and no, afaik, no human being can react within 0.2s. Human reaction time is on average ~0.5s
EDIT: You are all the same people who say "PERFECT RAID ROXXORZZZzZZzzz" (And it does). PR is what introduced the whole concept of bucketing after lots, and lots and lots of research into its implications. Clad is a master raid healer himself, and he knows what he's talking about
I always thougt healers on patchwerk would start their heals already before the offtanks got hit by hateful strike and I don't know any unitframes that show damage before it occurs... but .. whatever I'm not a healer so I don't know anything ;)
I guess people forgot that ag_Unitframes consist of Player,Target, TargetTarget, Party, Pet, Partypet, Raid, Raidpet, etc frames not just raid only stuffs.
It also does combat dmg text and a whole lot more.
Actually, it's about 0.5s average reaction time, 0.5s before frames are updated, between 0.1s and 1.0s for latency, not to mention who knows how many idiosyncrasies hidden away inside the game's code and your own computer's performance. Point is, if you're not proactively healing, you're not healing properly anyway. Even for instant spells. And yes, I've spent the better part of the last year as a raid healer.
Ideally, I would want raidframes that update faster than 0.5s, but I'm stuck playing on an old machine, in 800x600 resolution, I have to use addons that won't bog me down. It seems to me a slider for changing update times is the best solution. Everyone can have their cake and eat it, too.
P.S. Bring on the 25 man raids! Can't wait to have some decent performance in a raid, at last.
Edit ag_UnitFrames.lua starts at line 113 in latest SVN version:
self.HealthColor = {
r = 0.25,
g = 0.37,
b = 0.47,
}
self.ManaColor = {
[0] = { r = 153/255, g = 204/255, b = 255/255}, -- Mana
[1] = { r = 226/255, g = 45/255, b = 75/255}, -- Rage
[2] = { r = 255/255, g = 178/255, b = 0}, -- Focus
[3] = { r = 1.00, g = 1.00, b = 34/255}, -- Energy
[4] = { r = 0.00, g = 1.00, b = 1.00} -- Happiness
The solution is to increase the update rate, not remove it. Simple as that. It has nothing to do with the rest of agUF, or bucketed events in general.
As far as I know, ag is planning on adding a slider so you can choose how fast you want things to update. I just can't stand to see someone claim to have all the answers and push to remove something all-together when it should be tweaked or fixed instead. Removeing it is just going to cause more harm that good for MANY MANY users.
Fine. Let me start by saying that I have read and understood the inner working of AceEvent. Please understand that buckets are nothing more than collectors for events, and it calls the handler with a table on a throttled rate instead of on every fired event.
The first obvious flaw: it waits for at least the specified time before it notifies the event handlers. With 0.2s, that is 1/7 Flash Heal of lag.
Secondly, you obviously don't have any idea how a garbage collected heap works. Using terms like KB/s makes that quite clear. In a nutshell, instead of forcing the programmer to keep track of changes (malloc and free, new and delete), in a garbage collected heap you can allocate objects (tables in lua) without paying attention, and the wasted space gets recycled someday. Note that variables on the stack have nothing to do with that and as a result, calling UpdateHealth 100000x times will not create a single byte of garbage with your current code - there is no table creation involved.
The third flaw is that you claim that you cannot see a 1/10th second delay. That is obviously false. Try playing wow on 10 fps, and wonder why every game aims for the magical number of 30 (rts, rpg) or 60-100+ (shooters). If something happens with my raid - I want to know that asap, and not 0.2 seconds later.
And finally, the bad performance associated with non bulk updates is caused by the event handler itself. It doesn't check the UnitID that triggered the event, so everytime *any* hp changes, all 40 bars updates itself. Rule #3: Profile (or just read, ffs) the code first, *then* optimize (fix, in this case).
I, and my guild is pretty happy with an instanly responding raid frame, without any *measurable* performance hit. Next time, do your homework first, and then start pointing fingers. And make sure you actually measure the cpu load / time spent / gcinfo() in those methods instead of pulling numbers out of thin air.
The problem is, you run a high-level machine. High level machines can easily handle the full set of events, but lower level machines absolutely cannot. The whole point of the collectors (I hate the term buckets, not mine, btw) is to make the cost of the updates consistent whether you are in a raid, or out of a raid. Consider the following:
Register for UNIT_HEALTH and UNIT_MANA (leave focus, energy, rage out of it). Consider yourself in a 40 man raid.
In a span of 0.2 seconds, you can have a LOT of events firing (not even including UNIT_AURA). If you'd like to, you can check and see the rate of events that fire in the various fights (this has been optimized somewhat, and is certainly better than it used to be).
The fact remains, the best performance (defined as processing/memory and latency impact (i.e. how long it takes to perceive a change) outside a raid is to absolutely use the event system. The event system will give you instant response with minimal impact on the gameplay.
The best performance inside a raid is to update OnUpdate, in response to events. The frame rate for even medium level machines sits around 12 FPS during a raid. At 12 FPS you can respond to events within 0.1 seconds and get as instant response as you woudl with event handling. In this case, it could actually give you BETTER, due to the less overhead.
If you have a low end machine, in a raid, you shoudl unregister all events and update OnUpdate. Since you're only getting 2-3 FPS, updating each frame and ditching the event handlers gives you (literally) the best performance you can see. Since the graphics aren't being redrawn, updating the widgets is useless.
Its not a straightforward problem, but it is a straightforward solution.
EDIT: Also, ag_UnitFrames does CALL the handler once per unit regardless of whether or not the unit has been affected. It does NOT do anything (the first line of logic drops it out). The function call there is expensive, but shouldn't be the basis for the issues you're having. The reason for this is the OO design that ag is using, and the way he's handling the updates.
I personally iterate the table, and only update what's necessary.
EDIT #2: I _do_ algorithms. Its what I do. That being said, I 100% do not try to optimize code before its working, and without being fully educated. The whole reason for the slide you pasted is because too often peopel don't understand what optimization means. They can spend a day working on a path and optimizing it to absolute minimum cost, only to realize that it has no affect on their performance. You have to profile code, find your critical paths, and fully undertsand what and why everything is happening.
The concept of event collectors is fully applicable in wow, and very necessary in some cases to deal with the lower end clients. I stand by the use of them in general unit frames, however you have to know what you're doing, why you're doing it. The trunk versino of aguf is in development, and ag has said that. He's working on adding "features" and looking at some of the ways he handles things. People who don't like it can revert to a previous version while he works out his issues.
AG won't be back for two weeks, so suck up, revert, and deal. There's too much bullshit being flung in this thread from people who don't understand whats actually happening.
Works perfectly well for me. Somehow I doubt most healers would claim they need 43 frames updating faster than five times a second.
The problem is, there are handfull bosses in this game, where 0.2 delay on healing means death of tanks. Patchwerk is first on this list, twins and broodlord without best gear too.
I've downloaded turtoise, but i can't seem to find the right url :
http://svn.wowace.com/svnweb/index.cgi/root/browse/trunk/ag_UnitFrames/
doesn't work at least.
http://svn.wowace.com/root/trunk/ag_UnitFrames/
Only if I'd get a penny every time someone asks this...
I use aguf as a raidhealer. I'd like to see a person who's fast enough to react in 0.2 seconds :)
0.2 sec is more than enough to throw renew/rejuv/shield/NS heal/Swiftmend/ to save tank on ubs/swordspec/crushing sentence in twins fight.
Patchwerk throw hatefull strike evey 1.2 sec for 7.5k. 0.2 sec matter, again.
If you do proactive healing (And you should), then 0.2s doesn't matter, and no, afaik, no human being can react within 0.2s. Human reaction time is on average ~0.5s
EDIT: You are all the same people who say "PERFECT RAID ROXXORZZZzZZzzz" (And it does). PR is what introduced the whole concept of bucketing after lots, and lots and lots of research into its implications. Clad is a master raid healer himself, and he knows what he's talking about
But that would mean 0.5s + the 0.5s human reaction time. So it still makes a difference.
I guess people forgot that ag_Unitframes consist of Player,Target, TargetTarget, Party, Pet, Partypet, Raid, Raidpet, etc frames not just raid only stuffs.
It also does combat dmg text and a whole lot more.
Also its still beta so be gentle on this addon ;p
Ideally, I would want raidframes that update faster than 0.5s, but I'm stuck playing on an old machine, in 800x600 resolution, I have to use addons that won't bog me down. It seems to me a slider for changing update times is the best solution. Everyone can have their cake and eat it, too.
P.S. Bring on the 25 man raids! Can't wait to have some decent performance in a raid, at last.
A setting will be added shortly after ag' gets back from vacation, so let's drop the L2P argument and get back on topic :)
Edit ag_UnitFrames.lua starts at line 113 in latest SVN version:
self.HealthColor = { r = 0.25, g = 0.37, b = 0.47, } self.ManaColor = { [0] = { r = 153/255, g = 204/255, b = 255/255}, -- Mana [1] = { r = 226/255, g = 45/255, b = 75/255}, -- Rage [2] = { r = 255/255, g = 178/255, b = 0}, -- Focus [3] = { r = 1.00, g = 1.00, b = 34/255}, -- Energy [4] = { r = 0.00, g = 1.00, b = 1.00} -- HappinessProps to Sairen on his color choice.
Interface\AddOns\ag_UnitFrames\ag_UnitFrames-enUS.lua:1: Cannot find a library instance of AceLocale-2.0.