A few issues with my custom frames

[Hamlet]

I made myself some frames from scratch that I've been working on for a few days, and am having a few issues. Was wondering if someone could help me clean these up a bit.

First, a recovery file with everything I'm currently using is attached. Also, here's a YouTube video of them in action:
http://www.youtube.com/watch?v=4DiG3...eature=channel

The first issue is slow updating of auras. I use the AuraCache feature, as well as a multiplexer set to 0.2. But oftentimes I don't see my hots appear for many seconds after I cast them. For a good example, at 3:14 in the above video, you can see me cast a Rejuvenation on a Hunter (Czer) on the left side of the grid (you can see the mouseover highlight). The Rejuv AuraIcon doesn't appear for 9 seconds.

The problem is worst when I cast hots on myself. Even in the video segment I just mentioned, you can see me cast a Rejuv on myself at 3:20 and it doesn't appear for 4 seconds. This is commonplace--hots on myself never update promptly.

Finally, I have an occasional bug where I simply disappear from the frames. See this video (if the youtube is locked out for you due to copyright, there's a download in the info for the video):
http://www.youtube.com/watch?v=_mKRG...eature=channel
At 5:38, my frame simply disappears (status info reports LD) and remains that way for the rest of the fight.
At the same time, two frames change who they're representing over in the left column. The frame that had the Warlock Fearsom suddenly swaps to the Mage Empyrea, and the frame that had Empyrea gets the Shaman Kapetal (who's not even in the set for that window). I can no longer see Fearsom or myself in the windows for the rest of the fight.

Any help would be appreciated. Thanks!

[MNKyDeth]

Well, you could try two things to my knowledge with openrdx.

Set periodic repaint instead of the multiplexer parameters. Or, don't use either one in the frames and see how it performs that way.

By not including periodic repaint or the multiplexer I assume it defaults to a blizzard redraw default? (I really don't know I am not that experienced with openrdx yet).

I also know that periodic repaint might be a bit more cpu intensive but this is the route I have taken with my raid frames as a healer as I need to know "NOW" when the health goes down. This has made me the #1 healer in the guild I am in, in healing and overheals. Compared to using healbot with my druid I find that healbot also has a heavy lag issue to it. So while using periodic repaint for myself compared to healbot I still get better performance.

Or I could be way off on all this stuff and you can then just ignore what I just posted.

[Brainn]

from what i know openrdx windows/frames use the default blizzard-events, and then trys to guess wich frames need to be repainted on wich events. the multiplexer-parameter defines how often a window is allowed to repaint itself. so if you set this to 2 seconds, the window would only rebuild every 2 seconds, even if from the basic events it would have to repaint 2000x in that timeframe. this is used to reduce the cpu-load in case the frame would be repainted more often than needed (or fasten than a human can realize the changes). periodic repaint on the other hand forces the window/frame to repaint every X seconds even if there where no events that would cause a repaint. this is needed mostly for frames that dont get direct events, targettarget would be one example.
regarding the aura-stuff, there where problems with auras not getting updated as needed in the past, and those issues where simmilar to the ones you describe here. seems it all has to do with the aura-engine/aura-cache in general. the old issues i mean had to do with auras not repainting when refreshed, but they where fixed month ago.

[sigg]

Hello

I will add a security check to not allow multiplexer + auracache.

The auracache is only usefull when you are using a periodic repaint feature.
The auracache will be only allow in raid windows.

CPU usage low / Delayed event update
- Add a multiplexer with 0.2s
For example, you receive two or more events under this 0.2s, your window will only refresh 1 time at the end of 0.2.

CPU usage normal / Event update
- No multiplexer

CPU usage high / Real time update
- Add a Repaint feature (0.02s) + nohinting event (disable event registered)
- Add an auracache here

The Real time update is based on time and not event.

When an event is fired, all registered functions and frames will be executed serially. More you have addon listening same events, more it taking time to refresh. I am not sure about what I am talking here, but this is a idea I have.

This is the reason why you kill everyone in term of fast reaction when using Repaint feature.

Sigg

[Brainn]

Originally Posted by sigg When an event is fired, all registered functions and frames will be executed serially. More you have addon listening same events, more it taking time to refresh. I am not sure about what I am talking here, but this is a idea I have.

this is correct, all functions called when an event is fired have to be executed serially. i dont know in what order they get called, but im sure they are not executed parallel. im not sure how blizzard handles this on multicore cpus, but scripting languages in general execute stuff linear, not parallel.

regarding the periodic repaint: if i remember correctly, there once was a default multiplexer parameter of 0.1? that was removed a while ago to allow faster repaints through the event hinting system. since this was removed, i dont know how a periodic repaint could speed up the updating if all relevant events get register to repaint the frames/windows. could you explain this sigg ?

[sigg]

Are you talking about the periodic repaint value from the multiplexer option ?

[Hamlet]

Is 0.02 actually a safe value to set Periodic Repaint? And do I want to set it to RepaintAll or RepaintData?

Also, do you have any idea about the second issue?

[Brainn]

im talking about the event hinting system, aka windows without multiplexer parameters or periodic repaint.
from what i remember, there once was a default limit of 0.1 or something like that for repainting when there was no multiplexer parameter and no periodic repaint set in a window, but that was removed. now the windows should update on every event if there is no multiplexer parameter and no periodic repaint. with this, i dont understand how a periodic repaint could speed up display of information.

[sigg]

I dont understand how a periodic repaint could speed up display of information

Because blizzard events always fired with a very small lag.

To explain that, I will give you the example of the smooth power bar feature from Blizzard. The update of this smooth power bar is not base on event but on a "OnUpdate" script.

You can see this small lag by creating two windows, one using the smooth bar feature and the second base on event power frac.

Event the combat log event occurs faster than Blizard unitpower or unithealth.

The periodic repaint work like for all. But this feature required high CPU.

Sigg

[Brainn]

ok, now i understand. reminds me of an old addon called "instant health" or something like that i used back in sunwell times

[sigg]

Hi hamlet

during this fight, do you switch in a vehicle?

or can you provide a recovery file of your window?

thanks

[Hamlet]

Here's an updated recovery file of my current raid frame setup. You can see it in action is just about any of my videos:
http://www.youtube.com/user/Arawethion

[Hamlet]

I think I figured out the second bug from the OP. It seems to happen if somebody joins or leaves the raid group while I'm in combat (you see this in the video I linked from before, and I've noticed it more often recently).

[Hamlet]

Updated recently and still have the bug. Confirmed that it happens when someone enters or leaves the raid in combat. Moreover, if a person enters and then leaves (so the raid has the same people as when combat started), the frames go back to normal.

Seems like there's some problem with raidID's being updated when they change during combat.

[sigg]

Confirmed.

The process roster is still updating during combat.

A fix is coming