Curse

Actually, as much as I hate to admit it, WeakAuras' animations are not as optimally coded as they could be. It's a little embarassing for an addon that was originally created for the express purpose of using less CPU cycles than PowerAuras, and yet PowerAuras' animation subsystem is more efficient. Actually, when I first started working on WeakAuras, I actually planned to have no animation capabilities at all, because I knew an animation system would inevitably be a major source of CPU usage.

Where did things go wrong?

Well, of course, at some point in WeakAuras' development, I realized that it was going to end up being much more than a simple utility for my own use, but rather something I would want to share with the public. In that case, animations would be a highly desirable feature, so I felt obligated to include them. But, at this point in my addon development career, I didn't really understand Blizzard's Animation widget subsystem, which was a pretty new addition to the WoW API at the time, if I recall correctly.

Basically, Blizzard's Animation widget system allows a developer to specify certain preset animations to be applied to any UI element, and the WoW graphics engine will handle that animation. The idea is that WoW's graphics engine, which runs in native C code, will be much better at doing this than using Lua (addon) code to update the look of the UI elements on every frame. This is because whenever the Lua (addon) code has to interface with the C (WoW engine) code to get something to change graphically on screen, there is significant overhead involved. PowerAuras uses the Blizzard Animation widget system to animate things, whereas WeakAuras uses a custom animation system that is written all in Lua and updates on every frame.

So why not change WeakAuras to the faster animation system? A couple reasons. The most important reason is because the Blizzard Animation widget is very limited in terms of what types of animations can be specified and how those animations apply to groups of UI objects. In order to use the Blizzard Animation widget system in WeakAuras, I would have to either greatly reduce the capabilities of WeakAuras' animations - custom animation paths would be impossible, color animations would be impossible, all animations for Progress Bars and Progress Textures would be either impossible or very difficult - or use the system in such a heavy-handed and micromanagerial manner that it actually wouldn't provide any efficiency benefit.

I did, at one point, consider attempting to create a hybrid system: a system that would analyze the needs of any animation specification fed to it, run it on the Blizzard Animation widget system if possible, and use the custom Lua system if anything that was impossible with that system was needed. This ended up being far more of a hassle than I expected; messing around with the Lua animation system I had created often had far-reaching and surprising ramifications throughout the program, and getting even the simplest Blizzard Animation widget animations to work flawlessly with every other WeakAuras system (especially things like animated dynamic groups) was challenging to say the least. In the meantime, I came to realize that Blizzard's CPU profiling functions are very flawed, and started to question many things I thought I knew about CPU efficiency. In the end, I decided that it just wasn't worth the work, considering many of the most popular, unique, and useful displays and animation functions in WeakAuras (especially Progress Bars and Progress Textures) wouldn't be able to use the more efficient system anyway, and the Blizzard Animation widget system may not have been as big of an efficiency improvement as I initially thought.

Now, since I brought up the subject of Blizzard's CPU profiling functions (which are what BrokerCPU is based on) being flawed, I feel like I expand on that subject a bit. There are several major problems with it. The first is that it's often difficult to accurately attribute CPU usage to the proper addon, especially when libraries (like Ace 3) are being used. When an addon uses a function from a library, the CPU usage for that function will be attributed to the addon that first specified a need for that library. This is not really an issue that effects WeakAuras considerably, since I used very few libraries, but it's a big one for other addons, especially ones that depend on libraries heavily for combat event processing (things like BigWigs).

A more pertinent problem is that the CPU profiling functions also do a very poor job of profiling OnEvent and OnUpdate handler functions. If you're not familiar with WoW's addon code environment, OnEvent handler functions occur whenever a game event (such as a combat log message, an aura change, etc.) occurs, and OnUpdate handler functions are called on every frame of game animation (so, 60 times a second if you're running at 60 FPS). CPU usage statistics for these handlers seem to be attributed sometimes to the frames on which they are defined, attributed sometimes to the addon itself, and sometimes simply not registered at all. There was a point at which I had written a comprehensive CPU profiling suite for WeakAuras that was designed to measure the CPU usage of each of its separate subsystems (animations, event handling, progress bar and texture updating, config UI usage, loading/unloading, etc.) and each separate display defined by the user. But I had to cut the feature because the statistics shown were so inaccurate that they were entirely useless: some subsystems never registered any CPU usage, some considerably less than they should, the separate subsystem CPU usage stats never added up to the full addon CPU usage stat, the CPU profiler statistics never matched the values I obtained by inserting custom time-keeping code into various functions, etc.

Third, rather similarly, I'm not entirely convinced that the CPU profiling functions even "count" all CPU usage in the first place. It seems to me that they only measure Lua execution time, which means any time you're using particularly heavy WoW API calls - times when the Lua code will defer to the WoW engine's native C environment to get some work done - calls like the Animation widget system, the CPU profiler will just ignore the CPU usage of the "heaviest" part of your code. I never formally tested this suspicion, but suffice it to say, there is definitely a lot of CPU usage that the CPU profiling functions simply don't account for at all.

The final major problem with the WoW's CPU profiling functions is more philosophical than technical. The thing is that not all CPU usage actually affects your gameplay experience in the same way. I can think of no better way to demonstrate this than by WeakAuras' configuration UI's loading process. In the early versions of WeakAuras, it become immediately apparent that having a large number of displays specified would cause the configuration UI to "freeze" when you first tried to open it. This was because WoW game engine and the addon Lua code run on a single thread, which means that whenever an addon needs to accomplish some task, it literally pre-empts all other game functions - essentially, freezes the game - until that task is complete. Creating and displaying all of the sidebar buttons in the UI on the initial load of the WeakAuras configuration was taking too much time, and causing the game to freeze until it was finished. So, the solution to this problem: make the sidebar buttons "lighter" so they don't take as much time to load? No! The solution was to load the sidebar buttons one at a time and release control back to the game engine every so often so that frame updates etc. could still occur normally. This is essentially using the concept of asynchronous execution, which is very common in application programming, but not an available feature in WoW's addon code environment. But, it can be emulated using OnUpdate handlers and timekeeping code, and a lot of WeakAuras' heaviest tasks (which are almost all part of the configuration UI) are run on these emulated asynchronous execution handlers.

The point is that the loading process uses the same amount of CPU time as it ever did - probably more, because of the overhead of the asynchronous execution emulation - but it is a much much smoother experience for the end user because the CPU usage is spread over multiple frames. Realizing this, it becomes apparent that naively additive CPU usage statistics, such as those displayed by BrokerCPU, are not really enough to identify the addons that really effect your gameplay experience. They can be useful for catching addons that cause general framerate slowdown in heavy raid combat situations. But there is a much more pervasive and evasive problem in the WoW addon CPU usage paradigm that I refer to as "micro-stuttering", where an addon will spend several tens of milliseconds doing some large task, but use no CPU time anytime else. The amount of time spent can be so long that it causes a perceptible stutter in your framerate, or it can be subtle enough that you can't really tell it's happening unless you spend some time playing without addons and notice how much smoother everything looks all the time, even when your framerate reading is the same. I actually wrote a Broker addon that tried to catch these micro-stutters and provide CPU usage statistics only for the duration of the stutter... but unfortunately, because of the shortcomings I previously mentioned with regards to the CPU profiling functions, it turned out to be pretty useless. Some stutters would have identifiable culprits, but most of time, there would either be no or very little CPU usage by any addon during the stutter.

Anyway, this comment turned out to be far far longer than necessary to answer your question. I guess the TL;DR is that I'm acutely aware of the CPU usage of animations in WeakAuras, but I have no plans to change it. And you shouldn't really worry about it anyway. And if you are really worried about it, you shouldn't use animations in the first place.