CoolLine 

I wasn't sure what you were referring to with this statement when I wrote my last answer. After thinking about it for a while, I concluded you might be talking about my observation that the last frame of a fading Icon is usually clipped with your current code. This is not due to your linear function being wrong, but the order in which you do your operations. I might be wrong, but currently it looks like you draw the icon, then compute the new fade. Since the new fade is computed after the icon is already drawn, it takes effect on the next redraw. The problem is that the final fade before the the icon is removed is effectively skipped since it is computed, but never actually drawn.

I assume you're doing this to guarantee the first fully expanded icon has no fade.

Not a huge issue in my opinion, just something I noticed while goofing around.

I love CoolLine! It made possible for me to get rid of a bunch of button in my actionbars which I only used to watch for their cooldowns.

Can't live with CoolLine now.

I think I may not have worded something as clearly as I intended as I was not trying to say that. Your linear functions are probably the most accurate way to do what you're doing.

I think this comes down to us differing on our philosophy of what is the primary information we are getting from the addon. I see it primarily as a way to graphically depict the relative time between the spell's CDs. If I understand you correctly, you see it primarily as being a way to get the absolute time left on a spell CD. From my perspective, a spell "B" midpoint between two marks may not have a perfectly knowable absolute time left, but I'm fine with that as I can see that it is behind spell "A" and before spell "C". Therefore I know that I will probably activate spell "A" then spell "B" and finally spell "C" in that order as they come off of CD. You need to make the addon do what you like, I'm just trying to explain the way that I (and probably a few others) view the information that this type addon gives.

Again, I fully appreciate the time and effort you have put into this addon. I have fully enjoyed this conversion, as I am an engineer and debating technical design merits is fun for me.

The value I see in a cool down timeline is not as much the ability to precisely tell the absolute time left on a CD, as it is to give an intuitive feeling for the relative chronological order of CDs at a quick glance. Given this, the value I see in programming efficiency is not that the CD's position perfectly reflects its time left, but that it runs without using excessive resources on a marginal machine. We are also talking about a server/client game with a very real inherent latency. To me as an user, the aesthetic smoothness of an icon gliding down a logarithmic curve is worth a couple of milliseconds of absolute accuracy.

Another change I am playing with is during the final segment having the icon grow to " iconsize * 1.5 " and then snap to 0 on the timeline and " iconsize * 2 " once it hits 60ms time left. This is because I felt that it was a bit difficult to see the exact moment that the ability came off of CD when it very smoothly increased in size and then very smoothly faded out. A nice side effect of this change is that now the spells fade out completely instead of clipping the last faded frame. This is due to my adjusting the program execution order to evaluate the fade equation before setting the icon fade value (since now an average player will have 2-3 frames with the icon at full before it starts to fade.)


If I understand you right, you want the numbers to be spaced evenly. With the current log function I use, my markings are very close to exactly spaced like yours (the largest deviation from perfect is " section * 2.93 " at the 4th mark). My current bar is about 180 pixels long and I can't really tell that they aren't perfectly spaced. My last tick should probably read "4m" but I have mixed feelings about doing this.

Could this discussion be concluded perhaps by creating a "fork" of Cooline in the form of a "patch" or "optional files" maintained by Daphoosa that contains the version with logarithmic scale and whatnot? This way both we, the users and you, the authors would benefit: those who want logarithmic scale could get it, and totalpackage would not need to answer requests for log scale...

Just an idea.

Update:

I ran some tests and cannot measure a difference in cpu usage between a linear function version, and a log function version. I used Performance_Fu to do cpu profiling and watched the addon specific cpu usage as I increased the number of CD's. On my computer, with 9 CD's between 1s and 5m the max cpu usage for either version was the same at 0.35%. With a single CD, they both showed about 0.02% usage.

My first guess as to why this is would be is that the work of scanning for new CD's and then tracking current ones is so much greater than computing their positions that the extra cpu power needed to compute a log function is not significant.

I have not looked closely at Performance_Fu to see how it works and what it is actually measuring, but it seems to show both versions scaling as the number of CD's increases. This indicates to me that it is measuring something about the amount of CPU time that they are using. Given this, the relative difference it shows should be an indication of the performance even if the absolute value it generates is biased.

In conclusion, I appreciate your work producing this great addon and the care you have put into making it light and efficient. My interest here is only to try to help make it even better. Sincerely, ~Daphoosa

I appreciate your concern, but in my opinion, I think you're over emphasizing the computational cost. In a couple of seconds my throttling could be tweaked to a more moderate level. Also, anyone who is actually running at 60fps in a raid has plenty of cpu power to compute a single log per moving CD per frame. Note, I'm doing no Log computations for CD's at 5m and higher, and any 1s and under.

Anecdotally, I have been running 25man raids for a couple of weeks on a moderate computer with a full set of addons with no perceivable degradation.

On a side note, I have little desire to use ForteXorcist as your program is exactly what I need after a few adjustments.

edit: grammar/spelling

Just throwing this one out there (I totally respect where you're coming from, there are way too many authors who have absolutely no restraint), but what about pre-computing the log tables beforehand and then using them. Would that make that model feasible? I'm not even sure if that's something that could work or be done.

Interesting, I'd love to see how this works for two spells that are a GCD or so away from each other.. but sounds nice!

My partial solution to this problem involves a couple modifications. First I changed the time scale to stop at 5m. Cool downs above 5m just hover at the end of the line blinking, which is enough information to tell me that they're on CD, and that I have a lot of time before I need to worry about them. I also changed the intervals to 0,1,3,9,30,90,5m. By "stretching" the time just before an ability comes of of cool down, it is much easier to see which one is ahead and plan for it.

In addition to these changes, I have changed it to use a Logarithmic function to determine the icon's position when it is more than 1s from coming off of CD (The 1s to 0 interval uses the original code). This provides a much smoother acceleration as the spell travels along the bar. I use a linear function to adjust the throttling based on the time left, so spells at 5m update every 5s and spells at 1s update 60 times a seconds. Spells less than 1s update at 60/s.

@Totalpackage, if you want to see my modifications, send me a pm and I'll email it to you.

Yeah, the best I could come up with was text that is shown above, below, or next to the bar showing what spells are in each group. This way you avoid "stacks", but you only need one font string for each conflicting group.

I'll keep playing with it as-is and see if I can get used to it.