The entire reason it processes events only a few times a second is that it causes LESS lag. Instead of constantly updateing everything the INSTANT it's fired, it waits and does a single bulk update a few times a second. This is the main reason why ag_UF, PerfectRaid, sRaidFrames, all of these have better system preformance in a raid.
The changes you posted will cause MORE lag, due to the insane number of events fired per second in a full on 40-man raid. Your also removing the distinguising feature that cause this (and a few other recent Ace mods) to not destroy your increasing KB/S in raids.
Now, to start off, I don't know squat about coding in lua or in general, but I'm a user of this wonderful unitframe mod.
As a healer, I'd like to think I'm a healer with quite alot of experience, it is my opinion that the half second process "lag" is simply unacceptable. My heals are 1.5s casting time. The bar won't move until my next heal is done casting 1/3. I cannot be certain the target didn't got a similar amount of damage and therefor the bar didn't move. I have to be sure the instant the heal lands.
Now my guildie has modified it a bit as you've already seen and the bars indeed don't lag anymore. I understand your claim of this modification increasing lag in general, but sofar, I haven't notice any significant change in my computer's performance.
Increasing KB/s numbers are worthless to me if I don't know if the tank just got healed or not.
I still think this is a great UF, but to be frank, I can't use it if health bars lag half a second.
It shouldn't be updateing every 0.5 seconds, it should be updated 5 times a second, or every 0.2 seconds. (This is how often PerfectRaid updates and I know ag talked to Clad about implementing the bucket events in the first place.)
Increasing KB/s should never be meaningless, if they are too high you're going to get retarded amounts of lag, and you're heals won't even go off :)
I'll admit I don't use the agUF raid frames (I use PerfectRaid) but I have *never* noticed any lag on the party frames (of agUF) with the bucketed events. If that's not the case with the raid frames, and they *do* only update twice a second, I would reccomend upping them to 5 times (0.2), not completely removeing the functionality all together.
Just my opinion, I'd rather have a playable framerate than to have my raid HP bars updateing left and right 100 times a second.
suggestion::
change update rate in raids to .2 seconds
change classification to return "(Elite) " etc...
change unitframes color bassed off of classification
Shiina, I noticed this lag in BWL the other night. I just saw you posted the modification on the previous page, thank you. =)
Actually if you could attach/post the entire lua file - I have no idea where to put that modification. Hehe... that'd be great. =) Unfortunately, a a priest, I also can't play with the lag in updates.
Quote from Shiina »
Quote from Kyahx »
The entire reason it processes events only a few times a second is that it causes LESS lag. Instead of constantly updateing everything the INSTANT it's fired, it waits and does a single bulk update a few times a second. This is the main reason why ag_UF, PerfectRaid, sRaidFrames, all of these have better system preformance in a raid.
The changes you posted will cause MORE lag, due to the insane number of events fired per second in a full on 40-man raid. Your also removing the distinguising feature that cause this (and a few other recent Ace mods) to not destroy your increasing KB/S in raids.
Now, to start off, I don't know squat about coding in lua or in general, but I'm a user of this wonderful unitframe mod.
As a healer, I'd like to think I'm a healer with quite alot of experience, it is my opinion that the half second process "lag" is simply unacceptable. My heals are 1.5s casting time. The bar won't move until my next heal is done casting 1/3. I cannot be certain the target didn't got a similar amount of damage and therefor the bar didn't move. I have to be sure the instant the heal lands.
Now my guildie has modified it a bit as you've already seen and the bars indeed don't lag anymore. I understand your claim of this modification increasing lag in general, but sofar, I haven't notice any significant change in my computer's performance.
Increasing KB/s numbers are worthless to me if I don't know if the tank just got healed or not.
I still think this is a great UF, but to be frank, I can't use it if health bars lag half a second.
I noticed the same thing last time at Patchwerk, a fight were you have to be really fast as a healer.
I enabled combat text in the target frame, so i see the dmg taken on the tank, and have to go by that. The dmg shown by the bar is slower, and a really noticable diffirence. I thought i had some strange lag at first, but seems im not alone.
Just out of curiousity, why do you register every single frame as an event handler instead of going the 'procedural' way and update the right frame in a list? Getting OnUpdate called 40 times only to return instantly if the current frame didn't changed seems like a major waste to me.
_________________________________________________
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.
But that's not always the case, so you may try to cull updates that happens more than once a frame, but look at the code of AceEvent, and ask yourself: is the theoretically slightly better performance worth the overhead of bucketing with 0.05s (20 times/sec)? The most changes I have seen per second is 4 hits on our MT in a second (mob instant attack procs and skills) - why not process all 4 of them the instant that happens?
The best way to do the culling is with a Addon Global event handler for health and power changes, and track what happened in a semi-fixed size list of 40 units (I don't know about the underlying C implementation, but I bet it's grow-on-demand vector/arraylist). On each OnUpdate, process only the names occuring in the list and clear it. WoW Widget API calls are slow compared to pure lua, so this method keeps the amount of Set*'s to the absolute minimum.
If you're lagging badly, add a minimum time since last update timer to the tracking list, and skip updating the same frame more than [number between 2 and 5] times a second. This way you won't spam-call the external API. But always process the updates directly at the first event when you set a timeout, so at least the players sees the first change directly.
_________________________________________________
[edit] Digged up an old slide:
General Rules for Optimization
Rule #1 - Don't.
Rule #2 - Don't do it yet.
Rule #3 - Profile First.
Rule #4 - Optimize the algorithm.
Rule #4.5 - Cheating is often more efficient.
Rule #5 - GOTO 1.
#3 is a bit hard to do in lua, but I've modified TraceEvent to monitor CPU load (left as excercise for the reader, hint: do it smilar to the way it profiles gc-pressure). agUF (/trace aUF) isn't causing trouble even in direct update mode, as far as I can see.
Using the [aggro] tag for custom class produces this error:
ag_UnitFrames\ag_UnitFrames.lua:505: attempt to perform arithmetic on local `r' (a table value)
ag_UnitFrames\ag_UnitFrames.lua:505: in function <Interface\AddOns\ag_UnitFrames\ag_UnitFrames.lua:504>
<unknown>:
ag_UnitFrames\ag_UnitFrames.lua:1177: in function `ClassText'
ag_UnitFrames\ag_UnitClass.lua:625: in function `UpdateTextStrings'
ag_UnitFrames\ag_UnitClass.lua:653: in function `UpdateHealth'
ag_UnitFrames\ag_UnitClass.lua:442: in function `UpdateAll'
ag_UnitFrames\ag_UnitFrames.lua:321: in function `obj_method'
AceEvent-2.0\AceEvent-2.0.lua:289: in function `TriggerEvent'
AceEvent-2.0\AceEvent-2.0.lua:963: in function <...Ons\AcePlayerMenu\libs\AceEvent-2.0\AceEvent-2.0.lua:955>
<in C code>: in function `CameraOrSelectOrMoveStop'
<string>:"CAMERAORSELECTORMOVE":5: in main chunk
---
[white] works and nothing at all works as well. So probably just [aggro] broken.
Downloaded latest SVN and when i got raid frames on,KB/s increases very fast by up to 50 after 1m of playing.
I think that is why tekkub/mik reverted that - changing the bucket event to 0.2 seems to be very, very, very bad. The reason I didn't see that before is because MiniPerfsFu doesn't seem to work until you have been logged in for a bit.
I want to check with tekkub to make sure there isn't something else I'm missing with my revision, then I'll see about resubmitting without that change as I think the other feature additions are safe...
I think you're supposed to be creating branches when you're going to do a lot of changes... That way the original author can check it all out and merge it into the trunk if he likes it.
- The Filter Auras option doesn't seem to work as intended, at least not for my warlock (I don't see my demon armor buff).
- Add a character status option that will indicate the normal/resting/in-combat/dead/ghost status of the player. That would also be nice for the party/raid members as well.
- Two nights ago I thought I'd try aguf in a raid (BWL) and I barely managed to click logoff because the framerate dropped to 2fps. Haven't checked with the latest SVN build yet if anything improved.
I think you're supposed to be creating branches when you're going to do a lot of changes... That way the original author can check it all out and merge it into the trunk if he likes it.
Yeah, the more I think about it the more I realize I confused initiative with overstepping my bounds. The Highlight Selected was pretty much all in, there was just no option to toggle. The background option is pretty bad as well. The textures I added in the first place, so I'm not too worried about that one. The bucket event change was just lame on my part.
I think you're supposed to be creating branches when you're going to do a lot of changes... That way the original author can check it all out and merge it into the trunk if he likes it.
Yes, this is the reason why it got reverted back to original version :)
If you make some modifications in addons, commit them in branches under "addon/yournick" and notify the author about the changes.
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.
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.
Actually, I will. agUF is worthless to a healer.
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..
Now, to start off, I don't know squat about coding in lua or in general, but I'm a user of this wonderful unitframe mod.
As a healer, I'd like to think I'm a healer with quite alot of experience, it is my opinion that the half second process "lag" is simply unacceptable. My heals are 1.5s casting time. The bar won't move until my next heal is done casting 1/3. I cannot be certain the target didn't got a similar amount of damage and therefor the bar didn't move. I have to be sure the instant the heal lands.
Now my guildie has modified it a bit as you've already seen and the bars indeed don't lag anymore. I understand your claim of this modification increasing lag in general, but sofar, I haven't notice any significant change in my computer's performance.
Increasing KB/s numbers are worthless to me if I don't know if the tank just got healed or not.
I still think this is a great UF, but to be frank, I can't use it if health bars lag half a second.
Increasing KB/s should never be meaningless, if they are too high you're going to get retarded amounts of lag, and you're heals won't even go off :)
I'll admit I don't use the agUF raid frames (I use PerfectRaid) but I have *never* noticed any lag on the party frames (of agUF) with the bucketed events. If that's not the case with the raid frames, and they *do* only update twice a second, I would reccomend upping them to 5 times (0.2), not completely removeing the functionality all together.
Just my opinion, I'd rather have a playable framerate than to have my raid HP bars updateing left and right 100 times a second.
change update rate in raids to .2 seconds
change classification to return "(Elite) " etc...
change unitframes color bassed off of classification
Actually if you could attach/post the entire lua file - I have no idea where to put that modification. Hehe... that'd be great. =) Unfortunately, a a priest, I also can't play with the lag in updates.
I enabled combat text in the target frame, so i see the dmg taken on the tank, and have to go by that. The dmg shown by the bar is slower, and a really noticable diffirence. I thought i had some strange lag at first, but seems im not alone.
self:RegisterBucketEvent("UNIT_HEALTH",0.5, "UpdateHealth")to
self:RegisterBucketEvent("UNIT_HEALTH",0.2, "UpdateHealth")Just sounds easier to me ..
And I think it must automatic for healer class :)
So doing something like :
If UnitClass("player") etc...
Just out of curiousity, why do you register every single frame as an event handler instead of going the 'procedural' way and update the right frame in a list? Getting OnUpdate called 40 times only to return instantly if the current frame didn't changed seems like a major waste to me.
_________________________________________________
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.
But that's not always the case, so you may try to cull updates that happens more than once a frame, but look at the code of AceEvent, and ask yourself: is the theoretically slightly better performance worth the overhead of bucketing with 0.05s (20 times/sec)? The most changes I have seen per second is 4 hits on our MT in a second (mob instant attack procs and skills) - why not process all 4 of them the instant that happens?
The best way to do the culling is with a Addon Global event handler for health and power changes, and track what happened in a semi-fixed size list of 40 units (I don't know about the underlying C implementation, but I bet it's grow-on-demand vector/arraylist). On each OnUpdate, process only the names occuring in the list and clear it. WoW Widget API calls are slow compared to pure lua, so this method keeps the amount of Set*'s to the absolute minimum.
If you're lagging badly, add a minimum time since last update timer to the tracking list, and skip updating the same frame more than [number between 2 and 5] times a second. This way you won't spam-call the external API. But always process the updates directly at the first event when you set a timeout, so at least the players sees the first change directly.
_________________________________________________
[edit] Digged up an old slide:
General Rules for Optimization
Rule #1 - Don't.
Rule #2 - Don't do it yet.
Rule #3 - Profile First.
Rule #4 - Optimize the algorithm.
Rule #4.5 - Cheating is often more efficient.
Rule #5 - GOTO 1.
#3 is a bit hard to do in lua, but I've modified TraceEvent to monitor CPU load (left as excercise for the reader, hint: do it smilar to the way it profiles gc-pressure). agUF (/trace aUF) isn't causing trouble even in direct update mode, as far as I can see.
ag_UnitFrames\ag_UnitFrames.lua:505: attempt to perform arithmetic on local `r' (a table value)
ag_UnitFrames\ag_UnitFrames.lua:505: in function <Interface\AddOns\ag_UnitFrames\ag_UnitFrames.lua:504>
<unknown>:
ag_UnitFrames\ag_UnitFrames.lua:1177: in function `ClassText'
ag_UnitFrames\ag_UnitClass.lua:625: in function `UpdateTextStrings'
ag_UnitFrames\ag_UnitClass.lua:653: in function `UpdateHealth'
ag_UnitFrames\ag_UnitClass.lua:442: in function `UpdateAll'
ag_UnitFrames\ag_UnitFrames.lua:321: in function `obj_method'
AceEvent-2.0\AceEvent-2.0.lua:289: in function `TriggerEvent'
AceEvent-2.0\AceEvent-2.0.lua:963: in function <...Ons\AcePlayerMenu\libs\AceEvent-2.0\AceEvent-2.0.lua:955>
<in C code>: in function `CameraOrSelectOrMoveStop'
<string>:"CAMERAORSELECTORMOVE":5: in main chunk
---
[white] works and nothing at all works as well. So probably just [aggro] broken.
*credits to the original author of course *
(Middle mousebutton to lock/unlock portrait frames)
In combination with Adapt1.4 the 3D portraits are back^^
Ps: I just read the portrtait mod's author name - andreasG....coincidence or hazard?
I think that is why tekkub/mik reverted that - changing the bucket event to 0.2 seems to be very, very, very bad. The reason I didn't see that before is because MiniPerfsFu doesn't seem to work until you have been logged in for a bit.
I want to check with tekkub to make sure there isn't something else I'm missing with my revision, then I'll see about resubmitting without that change as I think the other feature additions are safe...
- Add a character status option that will indicate the normal/resting/in-combat/dead/ghost status of the player. That would also be nice for the party/raid members as well.
- Two nights ago I thought I'd try aguf in a raid (BWL) and I barely managed to click logoff because the framerate dropped to 2fps. Haven't checked with the latest SVN build yet if anything improved.
Yeah, the more I think about it the more I realize I confused initiative with overstepping my bounds. The Highlight Selected was pretty much all in, there was just no option to toggle. The background option is pretty bad as well. The textures I added in the first place, so I'm not too worried about that one. The bucket event change was just lame on my part.
Ah well, live and learn.
Yes, this is the reason why it got reverted back to original version :)
If you make some modifications in addons, commit them in branches under "addon/yournick" and notify the author about the changes.
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.
Actually, I will. agUF is worthless to a healer.
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..
Updating twice a second is useless to a healer.