Authors CurseForge

Quote from Nandini

Also, this does not account for instances where i would parent the casting text to an element other than the cast bar.

In that case, though, the text would already be visible, and whatever events it had registered for would be working.

Quote from Nandini

I've often wondered why these bars get hidden completely while not casting. Wouldn't it be unobtrusive enough to change the cast bar's color to match its background and set it to full, so it can register for the event directly? This way its anchored texts would also always be shown (even if you set the text to be some whitespace character) to register the event.

Also, this does not account for instances where i would parent the casting text to an element other than the cast bar.

It's an option to hide them. You can go back to the old method of not hiding the if you want under the bar options. A lot of people didn't like them taking up space and wanted their bars to resize to use the space but not lose the cast bar.

The only thing the UNIT_SPELLCASTING_SENT event is doing is capturing the spell, rank and target in variables. It's pretty unobtrusive. Even if you never used a castbar it's not chewing enough CPU time to even be noticeable if you manually went in and modified it.

That said if the cast bars are always visible the event would be tracked always anyways. Because then the castbars would be up.

So basically, people with castbars aren't seeing any change. If you're not using castbars you're eating a very small CPU cost for a feature you're not using.

As I said I may very well go in and provided an option to disable this, in which case you wouldn't even be paying that cost. But at this point the module was largely finished and providing this feature wasn't going to create configuration compatability issues so I decided to release what I had.

And just to drive home how simple this code is:

local next_spell, next_rank, next_target
function PitBull4_LuaTexts:UNIT_SPELLCAST_SENT(event, unit, spell, rank, target)
    if unit ~= "player" then return end

    next_spell = spell
    next_rank = rank and tonumber(rank:match("%d+"))
    next_target = target ~= "" and target or nil
end

That's it.

Framerate seems good, although I'm still getting occasional slow downs every second or so during 25-man raids only. I'm not sure if this is Pitbull, but every other frame rate issue I've had has been Pitbull (or indirectly, because of DogTags), so it's likely. I'm 100% on LuaTexts now, and my raid frames only have Name texts (this is the thing that fixed my frame rates for the most part prior to LuaTexts). It may be that there are further non-text optimizations that can occur in Pitbull for 25-man raids. In any case, it's much more playable now. Thanks for all the work! I hope at some point I can get a truly smooth-as-butter frame rate, since my hardware really should handle it. :)

I have a Status text on my player frame layout, and it's registered for the PLAYER_FLAGS_CHANGED. However, I can mash /afk and /dnd and nothing happens. I've also tried using UNIT_DYNAMIC_FLAGS and UNIT_FLAGS, with no effect.

I have a text that displays a creature's/character's race or their form if they are a druid. I currently have this registered to UPDATE_SHAPESHIFT_FORM and UNIT_STATS, but I'm really not sure about the latter. I have no idea on which event I should be checking their race/type. Hmmm.

Quote from Allara

Framerate seems good, although I'm still getting occasional slow downs every second or so during 25-man raids only. I'm not sure if this is Pitbull, but every other frame rate issue I've had has been Pitbull (or indirectly, because of DogTags), so it's likely. I'm 100% on LuaTexts now, and my raid frames only have Name texts (this is the thing that fixed my frame rates for the most part prior to LuaTexts). It may be that there are further non-text optimizations that can occur in Pitbull for 25-man raids. In any case, it's much more playable now. Thanks for all the work! I hope at some point I can get a truly smooth-as-butter frame rate, since my hardware really should handle it. :)

Probably 90% of our CPU time now is spent on updating what we call wacky frames (frames that Blizzard doesn't produce events for). We have to update them on a timer. A major change was made from PB3 -> PB4 with how we handle updating those frames.

In PB3 each module was responsible for having their own timers to update the wacky frames. The upside of this is modules could make their own choices about how to update. The downside of this is it made the modules a downright mess. Everyone of them had their own timers.

In PB4 the core is responsible for saying "Hey this frame is wacky it should be updated now." When that update happens all the modules get asked to do their updates. On top of this we made the core really smart about deciding what to update on timers.

In PB3 if the unit a frame pointed to didn't generate it's own events then it was always updated on a timer. 2.4 gave us access to GUIDs which gives us a way to know if 2 units are the same. So in PB4, if say you're targeting yourself, which means your target of target is also yourself. We know that the targettarget unit can be fed by the player unit events. So we stop updating the targettarget on a timer.

Unfortunately, there are still an awful lot of wacky units. Probably the ones that drag raid performance down the most are pets. The raidpet units do not generate events. All those frames have to be updated on a timer.

So getting back to the issue here. The improvement in code manageability and the removal of multiple timers has actually created a performance problem.

a) When a wacky unit gets updated all of the modules are getting updated at the same time rather than on their own slightly differing timers.

b) We're updating the wacky frames on a timer, however we're not spreading that load out over time. Every 0.15 seconds we're updating all of them. Then we do nothing for another 0.15 seconds.

This is what creates the stuttering effect in my opinion. I have a plan to fix this. It's just not something I've gotten to. Basically we'd load balance the updates like so. We'd take our update cycle and divide the number of wacky frames we need to update by the average number of frames we get in that cycle. So let's say you're getting 60 fps and there are 30 wacky frames to update. We want to update every wacky frame every 0.15 seconds. So every 9 frames is an update cycle. 30/9 = 3.333 so we'll update 4 units per frame. We'd keep a rotating buffer and just keep updating them.

This spreads the load so we're not trying to update all 30 frames on one frame.

Quote from link226

I downloaded and installed the most current version, and so far I'm very impressed. I did notice two bugs, however:
1. At one point a frame got so completely stuck to my cursor that I had to log out to fix it. I couldn't figure out how to reproduce this, though. I had the config menu open at the time, and was just moving the frame when it became stuck.
2. I was trying to configure the raid bars for a 10 man raid, but the bars refused to wrap to a new column, no matter what I set them to (even if I told it to only have one frame per column). I couldn't get it to do anything other than the default single column.

Both of these are known issues to me. Don't think there's a ticket for #1, but I know there is for #2. I can never seem to replicate #1 when I try, but I have seen it happen. #2 is simply an issue where it doesn't update the layout in config mode. The settings will take effect, you just have to reload for them to show up. I know this sucks. Sorry.

Quote from jokeyrhyme

I have a Status text on my player frame layout, and it's registered for the PLAYER_FLAGS_CHANGED. However, I can mash /afk and /dnd and nothing happens. I've also tried using UNIT_DYNAMIC_FLAGS and UNIT_FLAGS, with no effect.

There is no event for this that works reliably. PLAYER_FLAGS_CHANGED is the correct event. However, it doesn't always fire. The unit has to be within range, though it should work for you doing /afk or /dnd. Use the AFKDuration or DND flags if you just want to find out if someone is AFK or DND. You can ignore the actual return if you want. But if you get something they're AFK. Using those functions also tells LuaTexts to flag your text for updates based on when the afk or dnd flag changes.

When working to implement this I dug and dug trying to figure out what the hell UNIT_DYNAMIC_FLAGS and UNIT_FLAGS did, never did find out. Don't think they're relevent.

I have a text that displays a creature's/character's race or their form if they are a druid. I currently have this registered to UPDATE_SHAPESHIFT_FORM and UNIT_STATS, but I'm really not sure about the latter. I have no idea on which event I should be checking their race/type. Hmmm.

For Druid Forms you want UNIT_AURA.

UPDATE_SHAPESHIFT_FORM only fires if you're the druid shifting.

UNIT_STATS is for the paperdoll frame to know to update your stats, doesn't fire for other players.

Quote from Shefki

Probably 90% of our CPU time now is spent on updating what we call wacky frames (frames that Blizzard doesn't produce events for). We have to update them on a timer. A major change was made from PB3 -> PB4 with how we handle updating those frames.

Probably the ones that drag raid performance down the most are pets.

In our raid last night, there were five pets. Would PB4 be updating just those 5 frames, or does it need to continually scan for the possibility of more pets? I will try turning off raid pets entirely tonight.

I do have Debuffs turned on for raid members -- set to only show 3 of them. Does this introduce any sort of scanning/wacky updating, or is it entirely handled via WoW events? As a hunter, I'm more than willing to turn off things like this if it'll help.

My raid frames used to have a cast bar and these texts: name, health, cast, cast time. During Hodir-25, my frame rate was 3-5. I removed the cast bar and all texts except Name, and this alone bumped my frame rate up (I don't have an exact figure for that fight). When LuaTexts came out, I replaced all my texts (and didn't add any new texts), and turned off DogTags. My framerate on Hodir-25 last night was in the 17-25 range. This is perfectly acceptable (although I know my hardware can do better, more like 35-60). The issue that remains is the slight stutter that occurs roughly every 1 to 1.5 seconds.

It is the act of entering combat that triggers all framerate/stutter issues. This is why I've been mostly suspicious of anything that touches the combat log, or any unit frames.

I also don't notice any stuttering on 10-man. For example, I can verify that Yogg-Saron on 25-man will cause major stuttering issues, but on 10-man it does not.

Hopefully all this anecdotal evidence is helpful. I can provide more, and since I raid heavily on both modes, I can do a lot of testing if there is something specific you'd like help with.

Quote from Allara

In our raid last night, there were five pets. Would PB4 be updating just those 5 frames, or does it need to continually scan for the possibility of more pets? I will try turning off raid pets entirely tonight.

No Blizzard side code handles that for us from the SecureTemplates. It'd just be those 5 frames. But it's a full update not a limited update like what most events trigger.

I do have Debuffs turned on for raid members -- set to only show 3 of them. Does this introduce any sort of scanning/wacky updating, or is it entirely handled via WoW events?

Nope that's fine. The raid members generate UNIT_AURA events whenever their buffs/debuffs change and the Aura module refetches all the Auras. The limiting it to 3 is fine, that just limits how many we display frames for.

My raid frames used to have a cast bar and these texts: name, health, cast, cast time. During Hodir-25, my frame rate was 3-5. I removed the cast bar and all texts except Name, and this alone bumped my frame rate up (I don't have an exact figure for that fight). When LuaTexts came out, I replaced all my texts (and didn't add any new texts), and turned off DogTags. My framerate on Hodir-25 last night was in the 17-25 range. This is perfectly acceptable (although I know my hardware can do better, more like 35-60). The issue that remains is the slight stutter that occurs roughly every 1 to 1.5 seconds.

It is the act of entering combat that triggers all framerate/stutter issues. This is why I've been mostly suspicious of anything that touches the combat log, or any unit frames.

I also don't notice any stuttering on 10-man. For example, I can verify that Yogg-Saron on 25-man will cause major stuttering issues, but on 10-man it does not.

Hopefully all this anecdotal evidence is helpful. I can provide more, and since I raid heavily on both modes, I can do a lot of testing if there is something specific you'd like help with.

Not sure how helpful it is or not but it's appreciated anyway.

Upon the first summoning of my pet, many things about the frame often don't start out correct (it's class, it's level, sometimes even it's name). I realize these are game client issues. Would it be possible for the pet frame to, upon creation, schedule a full and complete update of itself for 20-30 seconds out? A workaround is to mount/unmount, but that's not always feasible.

Note that I'm not just talking about texts, but the color of the health bar and other things aren't correct.

Quote from Arkive

I see that Pitbull4 is still in alpha, but it looks quite promising. I have a fairly involved UI I maintain that relies heavily upoon Pitbull3. Is Pitbull4 ready for primetime, or should I hold off for a bit more before trying to integrate it into a published UI? Thanks.

If you have a decent computer, I'd say switch to PitBull4 now. It's still a bit rough on CPU utilisation, but aside from some optimization that I'm sure is coming, it's far far better than PitBull3. I loved 3, and now I hate 3 and love 4. :)
4 is missing a few nice things though, so check it out and make sure it does everything you need. I'd personally like a few more cosmetic options for debuff-highlighting, for instance. But if you can deal with that then 4 is amazing.

I disabled Ora2 tonight and the larger intermittent pauses seemed to go away. Now I'm left with some barely perceptible pauses that seem to fit in the 0.15 second window you mentioned earlier. Load balancing frame updates will probably smooth that out and we'll be in business.

Quote from Allara

I disabled Ora2 tonight and the larger intermittent pauses seemed to go away. Now I'm left with some barely perceptible pauses that seem to fit in the 0.15 second window you mentioned earlier. Load balancing frame updates will probably smooth that out and we'll be in business.

Now that's interesting. We do interact with oRA. Wonder if this isn't causing some of the issues. Though I have oRA2 installed and use it to feed my MainTank frames. I assume you had oRA2 installed with PB3 before with no issues? Wonder if I did something with the tank box support poorly.

Quote from Arkive

I see that Pitbull4 is still in alpha, but it looks quite promising. I have a fairly involved UI I maintain that relies heavily upoon Pitbull3. Is Pitbull4 ready for primetime, or should I hold off for a bit more before trying to integrate it into a published UI? Thanks.

For your personal use, sure. You may run into some issues but you can switch back and forth between PB3 and PB4. I have been. Slowly as I've been improving performance I've been switching to PB4. However, at this point I wouldn't think it'd be a good idea to include it in a published UI.

And it's alpha teetering on beta if I ever work out the remaining performance issues and close a few tickets I've not been looking forward to finishing.