Well did a quick search and there isn't much around on that subject so perhaps they hit a wall.

So far all I have seen is people utilising it on Enter and Leave scripts to do the different Fading functions. So how about this.

If you have an Update function that you call every so often perhaps you can put it in there to fadein if it has faded out or to fade out if it has faded in. Then keep a variable to store the last value updated. It's not perfect but might be the only way you can deal with it and even throwing the cycle in every event you watch may be a good idea too. The combination of the two functions may be enough to make it look passable at least.

You'll want to hide the frame doing the OnUpdate when it's done, else you'll be needlessly using CPU.

Just as a quick test, I set it to pulse my Minimap (lulz) and it's using so little CPU time that it could simply just be an error. By comparison, the tool I used to measure this used 24 times as much CPU time as the pulse addon.

Originally Posted by nightcracker

If this is going to be a reference, then I'll add something new, a variable to determine speed of the pulse in seconds(don't set it to 0, dividing by 0 FTW):

lua Code:

local speed =1

frame.mult =1

frame.alpha =1

frame:SetScript("OnUpdate", function(self, elapsed)

elapsed = elapsed*(1/speed)

self:SetAlpha(self.alpha)

self.alpha = self.alpha - elapsed*self.mult

if self.alpha <0and self.mult >0then

self.mult = self.mult*-1

self.alpha =0

elseif self.alpha >1and frame.mult <1then

self.mult = self.mult*-1

end

end)

Hm, I'll have to give that a go. In the previous incarnation, I was just adjusting the value of frame.mult to adjust the speed.

Just as a quick test, I set it to pulse my Minimap (lulz) and it's using so little CPU time that it could simply just be an error. By comparison, the tool I used to measure this used 24 times as much CPU time as the pulse addon.

Hm, I'll have to give that a go. In the previous incarnation, I was just adjusting the value of frame.mult to adjust the speed.

Woops, I actually made a mistake in the script, and you are right, it should be enough to change frame.mult.

FINAL VERSION(I hope):

lua Code:

frame.mult =1

frame.alpha =1

frame:SetScript("OnUpdate", function(self, elapsed)

self:SetAlpha(self.alpha)

self.alpha = self.alpha - elapsed*self.mult

if self.alpha <0and self.mult >0then

self.mult = self.mult*-1

self.alpha =0

elseif self.alpha >1and self.mult <0then

self.mult = self.mult*-1

end

end)

__________________
Three things are certain,
Death, taxes and site not found,
You, victim of one.

Just as a quick test, I set it to pulse my Minimap (lulz) and it's using so little CPU time that it could simply just be an error. By comparison, the tool I used to measure this used 24 times as much CPU time as the pulse addon.
<snip>

Profilers will use a huge amount of CPU because of everything they have to do for measuring every AddOn you're running.

Anyway: Saying "it's using so little CPU" and then ignoring that is rather dismissive - people running 200+ AddOns which do this are suddenly using a metric ****-ton of CPU for no reason whatsoever. If you aren't currently generating a pulse, the frame should be hidden so its OnUpdate will not be run.

Profilers will use a huge amount of CPU because of everything they have to do for measuring every AddOn you're running.

Well, yeah. Just using it as a frame of reference.

Anyway: Saying "it's using so little CPU" and then ignoring that is rather dismissive - people running 200+ AddOns which do this are suddenly using a metric ****-ton of CPU for no reason whatsoever. If you aren't currently generating a pulse, the frame should be hidden so its OnUpdate will not be run.

I agree that this is good coding practice, yes. My point is that for 99% of the people out there, having a frame that pulses indefinitely is not going to be an issue (as is the intent of my usage).

**EDIT:

Just discovered something while we're on the topic of performance that I thought should be part of this:

You can set this thing to absolutely ridiculous speeds (I've personally tried it up to 150, WELL beyond my refresh rate, just to see what would happen). The only upper limit here is your computers' crash threshold. BE CAREFUL WHEN DOING THIS. The reason it was/is using so little CPU is because apparently Blizz uses GPU time for this. On my machine at 1440x900, Ultra settings w/ some cVar tweaks, fullscreen windowed, and a frame pulsing at 150, I hit around 50%-ish GPU usage on average (peak no higher than 65%) with dual 5700-series ATis.

if you call it more than once(while it's active) - you'll need something that blocks this calls: (atleast for UIFrameFadeIn it makes it nearly go to infinite time - if called unnecessary times (even if you use :GetAlpha()) - you would need something like spareTime=totaltime-(GetAlpha()/totaltime))

(Note this is for UIFrameFadeIn, and not UIFrameFlash)

Code:

local fade_in = {}
local fade_out= {}
--improved UIFrameFadeIn(frame,time,startAlpha,endAlpha,~type)
function lib:UIFrameFadeIn(frame,t,startAlpha,endAlpha,typ)
local now=GetTime()
local fname = frame:GetName()
if typ=='in' then
local IsInTable,num = self:inTable(fname,fade_in)
if not IsInTable then
UIFrameFadeIn(frame,t,startAlpha,endAlpha)
--tinsert(frame,{icon_name,endTime})
tinsert(fade_in,{fname,GetTime()+t})
else
if now>fade_in[num][2] then
tremove(fade_in,num)
end
end
elseif typ=='out' then
local IsInTable,num = self:inTable(fname,fade_out)
if not IsInTable then
UIFrameFadeIn(frame,t,startAlpha,endAlpha)
tinsert(fade_out,{fname,GetTime()+t})
else
if now>fade_in[num][2] then
tremove(fade_out,num)
end
end
end
end

this would result in the AlphaProperty going from 0 to 1, then from 1 to 0 and so on. google 'math sin lua' for more info

Good luck

True, but that would require an onupdate function. And an onupdate function gets called at every frame. So if you run at 120 FPS your calling a sin function 120 times per second. Not that efficient as running my way(look above).

__________________
Three things are certain,
Death, taxes and site not found,
You, victim of one.

is more precise and does not skip seconds (even if this would just be some miliseconds) than reseting the whole value to 0 - (ie last_update could be 0.25182965 - so you would missing 0.00182965 - if you have this ~1000 times there's something missing