Especially in raid groups. Every time you change your title you trigger a UNIT_NAME_UPDATE event. This triggers an update of all the group headers because they blindly listen to that event and don't check the unit arg of the event to see if it's even a unit they care about. If the person doing this is in your raid and in the same party in the raid that you are you'll actually see two UNIT_NAME_UPDATE events for that player.

I've seen people running these addons in raids with the rotation time set as low as 1 second. This means you can be seeing 2 UNIT_NAME_UPDATE events per person doing this per second.

This is a horrible CPU churn. It's needlessly using CPU time of every single player in your group constantly.

I'd encourage players to stop using these addons at least in groups and/or in combat. Authors of such addons to reconsider distributing them or at least limiting their function outside of groups and/or combat. Baring a reasonable reaction from the community potentially Blizzard restricting the SetCurrentTitle() function.

This is a known issue since patch 2.1 two years ago. The workaround is for unit frames to unregister UNIT_NAME_UPDATE from the inherited group headers.

Remember years ago when zoning into AV or mass AV graveyard resurrections would cause lag or hangs? Same bug. Because each player res and pet respawn causes multiple UNIT_NAME_UPDATE to fire.

See http://forums.wowace.com/showthread.php?p=111494#post111494, a post made on 23 June 2007 by one of my guild members on behalf of me, and also the subsequent replies. The entire thread is about the zone/login issue with the UNIT_NAME_UPDATE churn.

This bug took me 2 days to trace and find btw and all major unit frame addons subsequently have this workaround applied and the bug was largely forgotten. Even Stuf Unit Frames has a "StufRaid> removed unnecessary use of UNIT_NAME_UPDATE event" in its patch notes 2 months ago.

Well this is interesting, but it does nothing for the people using Blizzard's frames. These title rotating addons are still producing unnecessary network traffic spamming everyone with the UNIT_NAME_UPDATE events. Unit frame addons need to use UNIT_NAME_UPDATE to properly update the name text when it changes. Granted we're checking the arg to the event so the impact isn't as bad.

I can understand the novelty of the idea of rotating the title. But some of these addons are allowing people to rotate their titles once a second. This is entirely gratuitous. If it wasn't putting a performance drain on other players then I wouldn't care. But it is.

Anyway thanks for pointing out the need to unregister UNIT_NAME_UPDATE on our group headers. The need for this got lost in the rewrite to PB4. I'll be applying this to help minimize these issues.

But I stand by my point that these addons are fundamentally bad for the game.

I wrote myself an addon to do this just out of curiosity. When I first used it a guild member noticed performance problems, which I didn't really understand. I guess this explains it.

Blizzard should either put a cap on title changing requests or fix their unit frames or clean up the event firing. It's pretty silly for an addon to be able to negatively affect other players' FPS.

Shouldn't you really be posting this on your guild's web site? I understand that this bug decreases performance of players but asking any addon authors to censor themselves is a bit out of bounds, also this should likely be addressed in the Bugs forums since this sounds like a known issue.

---

Q u o t e:
Shouldn't you really be posting this on your guild's web site? I understand that this bug decreases performance of players but asking any addon authors to censor themselves is a bit out of bounds, also this should likely be addressed in the Bugs forums since this sounds like a known issue.

---

This doesn't only affect his guild. Most people intelligent enough to write an addon are also intelligent enough to not write an addon that directly negatively affects the people they're playing with.

The best solution for this is Blizzard fixing this event, but until that happens addon authors shouldn't have a problem with giving up frivolous entertainment addon in exchange for not hurting the performance of people they're playing with.

---

Q u o t e:


This doesn't only affect his guild. Most people intelligent enough to write an addon are also intelligent enough to not write an addon that directly negatively affects the people they're playing with.

The best solution for this is Blizzard fixing this event, but until that happens addon authors shouldn't have a problem with giving up frivolous entertainment addon in exchange for not hurting the performance of people they're playing with.

---

True enough.

Yea it is worth noting that negatively affecting OTHER players could be viewed as very bad:

---

Q u o t e:
3) Add-ons must not negatively impact World of Warcraft realms or other players.
Add-ons will perform no function which, in Blizzard Entertainment's sole discretion, negatively impacts the performance of the World of Warcraft realms or otherwise negatively affects the game for other players. For example, this includes but is not limited to excessive use of the chat system, unnecessary loading from the hard disk, and slow frame rates.

---

---

Q u o t e:
Shouldn't you really be posting this on your guild's web site? I understand that this bug decreases performance of players but asking any addon authors to censor themselves is a bit out of bounds, also this should likely be addressed in the Bugs forums since this sounds like a known issue.

---

The issue is equally true if I run with a PUG, go into AV or any other battleground. If your neighbor is blasting their stereo so loud you can hear it in your house, it's really not rude to ask them not to do that. I certainly will be asking the player using these addons to knock it off. But I'm gonna bet that when I find them in AV they're gonna tell me where to stick it. So I don't think it's unreasonable to ask the authors to reconsider.

Even if the issue with the way the group headers respond to this event is changed (and I doubt it's a bug at this point given the people who posted on the thread Xinhuan linked to) it doesn't change the other impacts that these addons have on the overall game. More network traffic, more events generated, etc...

All I'm asking the title rotating authors to do is to at least limit the rate at which they rotate to something less ridiculous than once a second or simply stop rotating while in a group and/or combat. I think asking them to do that is a hell of a lot better of a solution than waiting till Blizzard notices the impact and just bans them or restricts the API.

---

Q u o t e:
All I'm asking the title rotating authors to do is to at least limit the rate at which they rotate to something less ridiculous than once a second or simply stop rotating while in a group and/or combat. I think asking them to do that is a hell of a lot better of a solution than waiting till Blizzard notices the impact and just bans them or restricts the API.

---

I believe this to be a reasonable solution.
I am preparing an update to AutoTitler which will allow the user to set a much longer interval while in a group or raid.
However if the users change the interval from its default it is your responsibility to either ask them politely to change it or upgrade your processor.

Edit: If you could provide the location of the code within the FrameXML that causes this 'cpu churn', I would like to review it.

---

Q u o t e:


I believe this to be a reasonable solution.
I am preparing an update to AutoTitler which will allow the user to set a much longer interval while in a group or raid.
However if the users change the interval from its default it is your responsibility to either ask them politely to change it or upgrade your processor.

Edit: If you could provide the location of the code within the FrameXML that causes this 'cpu churn', I would like to review it.

---

Sorry I didn't get back to you sooner. WoW forums were having issues when I tried to reply and then I forgot about it.

SecureTemplates.lua

Look at the OnEvent handlers. They trigger SecureGroupHeader_Update or SecureGroupPetHeader_Update in response to UNIT_NAME_UPDATE.

I don't think it's responsible for you to allow your addon to be configured in a way that creates a negative impact on other players. It's easy to say upgrade your processor. But as these addons become popular the problem is only going to get worse. Providing a configuration to lower the rate while in a group or raid is a good step. But I really do think you shouldn't let it be set to 1 second updates in those cases.

Even with the workarounds suggested by Xinhuan above I can tell you that things are still triggering some work because it causes the portraits to restart their animation at the start. I haven't bothered to track this down but my guess would be the Model frame is watching UNIT_NAME_UPDATE for who knows what reason...