• 0

    posted a message on ag_UnitFrames for Burning Crusade
    Quote from andreasg »

    Miles, one thing I can advice you to is change the value self.EMULATE_BC to true, as that will prevent aguf from doing layout updates while in combat (but queue it so that it updates when you get out of combat)


    k, will do (after I get ressed, HFC Blood Furnace + careless mage = gibbed)
    Posted in: Unit Frames
  • 0

    posted a message on Clique 0.2.0-Beta Released
    Quote from Isyn »

    I posted this on your Clique page at WoW Interface but I thought I'd post it here too.

    There are a bunch of recent reports that Click Casting is totally out in the expansion.

    http://forums.worldofwarcraft.com/thread.html?topicId=31015064&sid=1

    It appears that in Burning Crusade, Blizzard will be disabling all "click-to-cast" functionality in UI mods. (UI mods can no longer cast spells of their own accord during combat, even with a mouse click or button press.)


    No official replies yet, but I'm gonna be really sad if this is dead.


    That rumor is still spreading? oO

    IT'S NOT TRUE!

    In Burning Crusade, ALL UNITFRAMES HAVE CLIQUE BUILT-IN.

    It's easier to configure Clique-like stuff, from the SecureTemplate.lua:

    -- Although it may not be immediately obvious, we are able to use this new virtual button
    -- to set up very complex click behaviors on buttons. For example, we can define a new "heal"
    -- virtual button for all friendly left clicks, and then set the button to cast "Flash Heal"
    -- on an unmodified left click and "Renew" on a ctrl left click:
    -- self:SetAttribute("*helpbutton1", "heal");
    -- self:SetAttribute("*type-heal", "spell");
    -- self:SetAttribute("spell-heal", "Flash Heal");
    -- self:SetAttribute("ctrl-spell-heal", "Renew");


    Clique will stay as a very nice frontend to bind these actions, as raw SetAttribute is voodoo for most of us.
    Posted in: General AddOns
  • 0

    posted a message on ag_UnitFrames for Burning Crusade
    Quote from andreasg »

    Also, the secure raid anchors seem easy to use, yes, but a lot of stuff needs to be redesigned because the secure anchors CREATES the unit frames, and does not pool these created frames between each other. This actually changes a lot due to the way aUF is designed. This means that we need to create an unit object after a frame is created by the anchors.

    In aguf there is a unit object per unit frame, we can't have it that way anymore. I'm not even sure the secure anchors work yet, or how to execute code AFTER we're sure that all anchors have been updated. I think Cladhaire knows a lot about this stuff, but he isn't able to answer all of this yet.


    Yea, I couldn't figure out a way to convert aUF groups without major rewrites - I'll leave that for you since it's a total reengineering ;)

    For now, I'll just just not change party / mess with raids when in combat, or /rl after it (half a second, gotta love the load times without huge data collection mods)
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames for Burning Crusade
    Ahh, secure raid header be damned. Here is a link to the BC's FrameXML, I extracted them from the mpqs yesterday, maybe you will find some ideas how to rework aUFgroup: http://elektron.its.tudelft.nl/~chkwok30/oekaboe/FrameXML.rar

    I'm a bit dazzled by aUF's group sorting atm, but the secure template seems pretty easy to use. You can SetAttribute these stuff on it:

    --[[
    List of the various configuration attributes
    ======================================================
    nameList = [STRING] -- a comma separated list of player names (not used if 'groupFilter' is set)
    groupFilter = [1-8, STRING] -- a raid group number or an uppercase class name
    point = [STRING] -- a valid XML anchoring point (Default: "TOP")
    xOffset = [NUMBER] -- the x-Offset to use when anchoring the unit buttons (Default: 0)
    yOffset = [NUMBER] -- the y-Offset to use when anchoring the unit buttons (Default: 0)
    sortMethod = ["INDEX", "NAME"] -- defines how the group is sorted (Default: "INDEX")
    sortDir = ["ASC", "DESC"] -- defines the sort order (Default: "ASC")
    template = [STRING] -- the XML template to use for the unit buttons
    ======================================================
    --]]

    It should save a lot of code, but I'm not sure setting a template is enough to initialize a aUFunit. A 100-lines methode, SecureRaidGroupHeader_Update, will do all the hard work depending on what you set in the attributes.


    Target's target is solved by changing aUFunit's UpdateVisibility() to (ugly hack incoming!)

    if self.visible == true then
    self.frame:Show();
    self.frame:SetAlpha(1)
    else
    self.frame:SetAlpha(0)
    end

    It also solves the one-shotting stuff in Elwynn Forest = Target frame won't get hidden, you are in combat problem.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames for Burning Crusade
    Quote from andreasg »

    Miles, I know the secure frames aren't a big deal for party frames, but there is a lot of work to do for the raid frames. Image if raid member raid34 leaves in a 40 man party, this means that the layout for all the frames needs to be updated, frames moved around and stuff like that, because everyone will get a new raid id in this situation. As unit frames cannot be moved in combat in BC, this isn't possible.

    It isn't possible to do in BC unless you use the special secure raid headers which means that the frame creation and grouping code for the raid would have to be written to support this new stuff. But as I said I'd like to start working on that, but unfortunately I do not have a BC key, so I can't begin.

    I know that raid frames probably seem to work, but they won't.


    Hmm, it's some really black voodoo you've got there.

    As far as I can see, Blizzard's targettarget updating algorithm just uses :Show() and :Hide(), but agUF's can't. My current workaround is :SetAlpha(0) and :SetAlpha(1) - I don't see any other way to do it, yet.

    It really sucks that you can't just poke Blizzard, saying you have written an addon thousands of users uses, and get a key to update it. I'm already happy that I finally got rid of the default UI, even if it won't work when you change the groups around in combat.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames for Burning Crusade
    The secure template thing is a lot less complicated than most assume. As everything in agUF is created from one template, only one line of xml was changed:

    <Button name="AGUnitTemplate" frameStrata="MEDIUM" movable="true" parent="UIParent" hidden="true" virtual="true" inherits="SecureUnitButtonTemplate">

    Further, Reset gained a few lines:

    self.frame:SetAttribute("unit", self.unit);
    self.frame:SetAttribute("type1", "target");
    self.frame:SetAttribute("type2", "menu");
    self.frame:SetAttribute("*type2", "menu");
    self.frame.showmenu = self.OnShowMenu;
    self.frame.parent = self;

    a new OnShowMenu was created, it uses the same logic as the old OnClick: ctrl/alt = config, rightbutton = standard wow dropdown, left click = target is done with attributes.

    Other changes are mostly for k,v in table -> for k,v in pairs(table).

    --

    Raid frames works fine, just tested it again, made a little group and dragged myself around in group 1-8 and agUF behaves like in 1.12. The same goes for party frames.

    --

    known issues:

    - unitframes cannot be changed in combat, so weird stuff can happen. I don't have an idea yet how to fix that.

    --

    svn: permission to do whatever you want with the code is given, so please upload a branch if you wish. I don't have wowace svn access, as I run my own dev repository :P

    I'm not really for the new enduser leeching from dev builds thing, as it encourages release before testing.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    The delay is the bucketed update, in order to lower CPU usage it introduces an update delay. I've been using a direct update patch since the beginning because of it, because the author doesn't agree with my view: 'screw cpu usage, I want to see what happens asap'.

    Bucketed update for mana/rage/energy is fine, HP is not.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames for Burning Crusade
    [rewrite of start post]

    Development of ag_UnitFrames has been shifted to primairly for TBC, the live version is on maintainance mode. If new features are 1.12 compatible, it will be backported asap, but no guarantees are given.


    Download:

    Releases: http://www.wowinterface.com/downloads/info5468-ag_UnitFrames.html

    Pre-release:
    http://svn.wowace.com/wowace/branches/ag_UnitFrames/TBC/ag_UnitFrames/
    http://www.wowace.com/files/index.php?path=ag_UnitFrames/ [TBC] tagged archives.


    Issues Tracker:

    We have a problem with too many threads and too many issues/requests on a lineair page, causing headache and forgotten / not seen posts. To solve this, we've registered a issues tracker on google, so every issue and suggestion get it's own thread, correctly tagged for 1.12 / TBC / PTR, defect of enhancement, etc.

    The tracker is located at http://code.google.com/p/agunitframes/issues/ - please use that instead of the forums to report problems and suggestions.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Quote from andreasg »

    For the people who used Miles' version, could they check the SVN/trunk version now to see if the performance problems are gone?

    http://svn.wowace.com/files/


    Didn't play-tested it in a raid yet, but it seems that the largest issues should be gone. But I'm curious why UNIT_HEALTH isn't on a fast-queue / direct update method instead of buckets, because while 0.5s delay is fine for MT healing, it's deadly for mages, for example at bwl post-broodlord trash with those goblins. It's not like that 7 microseconds per event is a very high price to pay compared to bucket overhead.

    Anyway, with the UNIT_AURA -> 0.5s per 4, multiple registration of target's target updater bugs fixed, the performance cost of agUF should be next to zero.

    However, it will take a raid 5 seconds to turn purple when a mass-curse (@ luci for example) comes, and the UNIT_HEALTH/MANA handling with 40 + player + target + tt seperate handlers is a waste imo.

    And finally, I see that UpdateTextStrings still updates more than needed, that increases the cost of UpdateHealth and Powers dramatically. Maybe an idea for the next revision.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    I've just found a new choke-point: performance drops when someone is targetted in a really busy fight. Added origin tracking to UpdateAuras, and it showed 700k calls in 1 hour of raiding from UpdateMetro(), at 1.4M frames rendered in total (AuraQueue calls). That's a call every other frame, maybe more in a fight.

    Switched to metrognome + 0.5s updating @ target's target. I have no idea why the other code went crazy, but the stats for a Nef kill was:

    Method - Calls Time
    UpdateAuras: 3328 0.768
    UpdateAll: 809 0.499
    UpdatePower: 9090 0.157
    UpdateHealth: 4524 0.247

    Aura Call Counters:
    aUF-Metro: 565
    Auras Dispatched: 2087
    Auras from UpdateAll: 676


    Updated at http://elektron.ewi.tudelft.nl/~chkwok30/oekaboe/ag_UnitFrames.zip (note: another see problem, patch problem (hansaplast style) release. If you can wait - get updates from svn)

    [edit] spelling
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Hmm, just tested the download, seems fine here. Mirrored at http://elektron.its.tudelft.nl/~chkwok30/oekaboe/ag_UnitFrames.zip now.

    [edit] zipped it too, url -> .zip.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Ack, just noticed today that I made a few mistakes in the aura processing functions... Damn, I was out of shape when I wrote that :P


    agUF - Temporary Replacement Event Handler patch 0.1

    Fixed a big bug causing update problems on auras - it wasn't updating correctly sometimes, also performance was lower than expected -> solved.
    Fixed a bug related to UNIT_HEALTH, double registration = lower performance (2x 7us zomg)

    Download: http://digibites.net/wow/ag_UnitFrames.rar


    Note: lazy-mode zip the directory style release, includes modded raid frames, you only have to extract 3 files for the event handler: the toc, ag_UnitClass.lua, ag_UnitClassEvents.lua, and MetroGnome in libs dir if you don't have it yet...

    Libs dir is a ntfs-hardlink here so I don't have to checkout externals every single each mod -> one folder to update them all. It includes a lot of stuff from other mods.

    This is only intended as a short term fix for 40 man raid performance, use the svn versions if you don't need it. Other bugs may exist!


    Stats from a short AV (15m zergness) with my mage:

    Method - Calls Time KB Time/call
    UpdateAuras: 8392 0.956 1 (113.9 us)
    UpdateHealth: 10450 0.628 265 (60.1 us)
    UpdatePower: 14837 0.367 29 (18.0 us)
    AuraQueue: 30831 0.481 0 (15.6 us)
    UpdateAll: 4611 0.875 48 (189.8 us)

    Auras Dispatched: 3300

    ~0.35% of the time is spent in agUF, in a 40 man raid.


    [edit] added stats, and explaination of the numbers.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Quote from cerement »

    Miles -- from comments I've seen on other projects on the boards here, sounds like if you want to make things available through SVN, it would go under "branches" under addon name then a directory with your name, then let andreasg know when he gets back.
    ie. http://svn.wowace.com/root/branches/ag_UnitFrames/miles/



    The diffs don't make much sense, too many changes - it's best to let andreasg to read through the code and let him decide what to implement, as a merge will give quite a lot of conflicts or worse, non working code without any warning. Also, I'm not planning on commiting more stuff, and the licensing isn't clear yet (GPL? MIT/BSD? public domain?), so I'm not branching it.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Went digging in UpdatePower / UpdateHealth, and saw that I short circuited the update strings at the end: so that method causes a x10 slowdown. Pff...

    Changed it into:

    function aUF.classes.aUFunit.prototype:UpdateTextStrings(texttype)
    	local dohp = texttype == nil or texttype == "hp";
    	local domp = texttype == nil or texttype == "mp";
    	local doname = texttype == nil;
    	local doclass = texttype == nil;
    	
    	if aUF.HelperFunctions[self.type] then
    		if dohp and aUF.HelperFunctions[self.type].HealthText and self.HealthText:IsVisible() then
    			aUF.HelperFunctions[self.type].HealthText(self.unit,self.HealthText)
    		end
    		if domp and aUF.HelperFunctions[self.type].ManaText and self.ManaText:IsVisible() then
    			aUF.HelperFunctions[self.type].ManaText(self.unit,self.ManaText)
    		end
    		if doname and aUF.HelperFunctions[self.type].NameText and self.NameLabel:IsVisible() then
    			aUF.HelperFunctions[self.type].NameText(self.unit,self.NameLabel)
    		end
    		if doclass and aUF.HelperFunctions[self.type].ClassText and self.ClassText:IsVisible() then
    			aUF.HelperFunctions[self.type].ClassText(self.unit,self.ClassText)
    		end
    	end
    end


    Performance in μs (loops of 100k, 10k at auras):

    UpdateTextStrings() - 4.84
    UpdateTextStrings("hp") - 1.87

    UpdateHealth() 7.18
    UpdatePower() 7.78

    UpdateAuras() 160.4
    UpdateAuras(), style=hide: 32.8

    _________________________________________________

    A pretty nice performance boost in the core, from 78μs to a bit more then 7μs for normal hp/mana updates. Auras are still a problem, but it is queued and if you don't show auras on raid frames, it should use the optimized route for a x5 speed difference. Also, not all UNIT_BUFF events triggers player and target frame to redraw the auras as it used to be, the new dispatcher knows who to notify. I suspect that is the main reason for lagginess in raids.
    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames (Release 7/19/2006) alpha version
    Desperate times calls for desperate measures. I have noticed horrible performance hits on bosses with mass afflictions and aoe damage, with Luci as the worst frame-freezer, so I took two hours off and went analyzing the performance.

    On those bosses, UpdateHealth, UpdatePowers and UpdateAuras gets called pretty often, with the cpu load in the ratio: 1, 1, 5. Health were changed to direct update with unit id checking, powers and auras queued per 0.5 seconds. The total time spent in the three methods are 21% of elapsed time, which pretty much comfirms my hypothesis that those 3 needs some changed.

    _________________________________________________
    Instead of spending extra time in event handler calls because every frame handles its events, I disabled registration of those three events. One event handler will do, no need for 40 of them, and the events gets dispatched via aUF.units[id].UpdateHealth, Powers and Auras.

    UpdatePowers is quite interesting, it sets the color on every update, which is quite a waste of time - it's not like a mana bar will change into energy between calls. Remember the previous power type and update on change.

    UpdateAuras - the worst offender in the class. Instead of posting events directly, the unit id is added to a first in first out queue (wrap around + static sized array). With the help of MetroGnome, a ProcessAuraQueue function will process up to a preset amount of changes per frame (and can easily be changed into an interval), with 5 as default. This way I avoid a small hiccup when a boss puts a curse on every single player, 5x 0.145ms = next to no delay, the queue will get processed further next frame.

    UpdateAuras also got my attention because it required 0.145ms per call, which is more than 20 times than the other functions. After a quick inspection of the code, I added a little piece of code that boosted performance beyond measurement.

    Flow:

    for i=1,20 do
    * Hide Aura
    * Check for buffs and debuffs
    if style == "Hide" or bcount + dbcount == 0 then return
    ...

    The hide each aura, UnitBuff and UnitDebuff calls are cross-language, so they are very expensive compared to pure lua code. Since most raid frames don't show auras, a shortcut is available:

    New flow:

    local hide = style == "Hide"
    for i=1,20 do
    * if (not self.hidden) Hide Aura
    * Check for debuffs
    * if (not hide) check for buffs
    end

    if style == "Hide" or bcount + dbcount == 0 then
    self.hidden = true;
    return;
    end
    ...

    Further optimizations can be made when auras are shown: only hide the ones shown, and have to be hidden, and the other way around. The code below the first loops is a bit too funky to read at this time.

    _________________________________________________

    These few optimizations, especially the aura queue, eliminated all the delays I've noticed. The aura updating process can still use some updates, but with the already hidden check, eliminating 2/3 of the expensive calls, the performance went from bad to only measurable delays.

    local t=GetTime();
    
    for i = 1,10000 do
    aUF.units.target:UpdateAuras(true);
    end
    
    MC_Print(GetTime() - t);


    Aura Not shown: 0.0033ms / call
    Aura shown: 0.068ms / call

    Worst case frame delay: 0.34ms (@ 5 frames processed from the queue with aura shown)

    Also, because UpdateHealth / Powers are not bunched up to be updated at the same frame, small hiccups each 0.x seconds is also history. If needed, they can be convered to a queued structure too, but as they only take 0.105 ms (health. update strings slow?) and 0.0078 ms (powers) each call, it will be hard to make the overhead lower than that.

    _________________________________________________

    To sum it up:

    UpdateHealth:
    Before: bucket & direct, each instance is a handler.
    After: direct, one handler dispatching events to the right frame. The call itself still takes 0.078ms.

    UpdateMana:
    Before: same as above. Sets color each update.
    After: direct, one handler. Bypasses color setting when it stays the same. (x10 speedup compared to old routine). There is no way that AceEvent bucketing can improve performance here anymore - 0.0078 ms (not a typo) per call is lower than the overhead.

    UpdateAura:
    Before: bucketed, very slow
    After: queued, max 5 unitframes updated per frame (~0.5s @ 15fps to update 40 frames). 20 times faster with hidden auras (only process the highlight + find debuffs), otherwise still 0.15ms each call, or a 0.75ms 'spike'.


    PS There is something fishy about UpdateHealth. I can't see it right now, but as it follows the exact same structure as UpdatePowers, it really shouldn't take 10x longer to display. I suspect there is a handler / function override for the color change on hp change, but I can't see it yet.

    PS2 I enjoyed hacking in this code, but I doubt that svn will be the best place to post such a large update. A first version can be found on http://digibites.net/wow/ag_UnitFrames.zip - but beware that it needs more testing since replacing the way events are handled + numerous updates in the handlers itself is no small change, you may want to revert to an 'official' version before entering major raids. The files are released with the MIT license, and a diff is included. And btw, you can macro /script aUFS.printTrackStats() to monitor performance. The event handlers requires MetroGnome.

    PS3 I just got an idea how to optimize the aura shown case, but it's too late to start coding now, maybe tomorrow. Idea is to override :Show() and :Hide() to check a self.isVisible variable first, and call the blizzard methods when needed.

    If you wonder why I'm doing this - I just want to play the game without being lagged to pieces. agUF's raid layout (customized, ofc) is the best thing I've seen in a long while, and the addon itself isn't bad either, it just needed a bit healthy dose of tweaking (still alpha).

    Feature requests: update tooltip to use the CT_RA's if available - I miss the mouseover for battleress cooldown function. Buff durations from CT_RA (also shown on hover) would also be nice, and an option to show fortitude, intellect, mark, ss like in CT_RA on the upper right corner, extra will be nice too, and bonus points for a key binding to toggle the visibility of that.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.