Registering for all events / asynchronous code execution
I need kind of an event log for one of my addons.
Is there a concise way to register a frame for all possible events? |
RegisterAllEvents
/etrace might also be useful. |
Thanks for the instant and very concise reply! ;)
I guess I could have googled this myself... :o Regarding the remark: "It is not advisable to use this for anything except debugging purposes, as the incurred performance penalty is quite large." Do you think this is still an issue with today's computers? I have never noticed that having /eventtrace open would give me any performance penalties. |
It depends on how much "extra" processing you might add to the event call(s).
On it's own it's probably not an overly great burden. |
All right, I will give it a try.
I just want to continuously log the events of the most recent second or so, such that under certain circumstances I can see what has just happened. Thanks again! |
It'll keep calling your OnEvent handler for literally everything. Especially in combat, this happens a lot. Calling a Lua function is the most taxing operation you can do. The best you can do is to make sure the game spends the least time possible in Lua code. Even if it's just an empty function.
|
Quote:
Another thing I was wondering: Is it more efficient to have one frame listening to several events and decide what to do depending on the event within the one OnEvent function. Or to have several frames each listening to only one event? Or does this make no difference? |
Quote:
Quote:
The overall goal is to have code that's easy to read and maintain, but not be too wasteful of CPU time if you can help it. Quote:
|
Thanks for the advice.
One more thing I have been thinking about. Do you think there will ever by a major update that will allow something like "asynchronous" execution of lua code? At the moment it seems that the framerate is determined by whoever is slower: the GPU rendering the game world or the CPU executing any pending UI code. Normally, the UI does not take that much time. But actions like e.g. opening the "Appearances" frame brings with it a massive momentary FPS drop. The same is true to a lesser degree for just openning your bagpack (also without any addons). And even picking up an item while your backpack is open leads to 1-2 frames with a lower rate than the GPU would be able to render. How fundamentally different would it be if the GPU does its thing rendering the game world as fast as possible and the lua code does its thing taking as long as it needs without throttling the FPS...? |
Lua is a single-threaded scripting engine, so async threads are impossible. You can fake it though by spreading your workload using coroutines or other fancy coding. You end up passing execution around like a hot potato instead of it truly being asynchronous.
It may be possible for Blizzard to separate the render and Lua into their own threads, but that's entirely up to them. |
Quote:
But it's not easily to be done, we can't make all authors to use the coroutines, also we can't make all authors to use the coroutines under the same framework. You can check my Scorpio-Async FrameWork for some ideas. Since most addons I used are created by my own, I can make all codes processed without fps dropping, but that only works for myself. Somebody told me, the Scorpio is largely used in hack-apps like automatic combat for performance, it's sad that it's popular in a wrong direction. |
Quote:
I mean you somehow have to "pass the execution around" (like SDPhantom said) from frame to frame, right? So when WoW is running at 120 FPS you do less lua executions per frame than when it is running at 60 FPS? How does your framework estimate how many lua executions "fit" into one frame, before the FPS would drop?? |
Quote:
Lua Code:
Dont' mind the __SlashCmd__, it means use command "/sct start" to call the function bigCycle, the __Async__ means the function will be processed in a coroutine, there are many ways to simple code like this. The blz provide the debugprofilestop, so we can mesaure the cost of code in one frame(The GetTime() can't do that, since it won't change the result during one frame) The core part in the example is the Continue API provided by the Scorpio. It'll yield the coroutine, queue it to a high priority task list. So the code is stopped, the task schedule system will check if there is still enough time in one frame, if it's has, the system will check the task list, and resume each task one by one until there is no task or not enough time. The time limit for one frame is calcluated by the fps, it is less in 120 hz game than the 60hz(but normally the CPU is more powerful in the 120 Hz hardware platform). The system will also try to calcuate the average cost of the codes(from resume to the yield, since many codes doesn't finish in one frame), so if there is too many tasks, the task system will try to get more time to reduce the amount of the tasks, but with a max time limit, the fps dropping could be unnoticeable, we still can change the max time limit to make sure no fps dropping. So to dot it, we need a task schedule system to manage the time and resume the tasks, and several async APIs like the Continue, Delay and etc to queue the tasks into the schedule system, so we can manage them no matter where and how the code works. |
Cool, it's great to know that something like that exists. Maybe some day I will try to implement a bag inventory that gets updated without FPS drop when looting something. :)
|
This makes sense, actually. I've considered adding a flag my addon to detect when something like UNIT_AURA has happened a bazillion times in just one frame, and waiting until the next frame to execute the code only once. The downside is that you are imposing 'latency' on the player.
In theory, they will see the information one frame later and thus have a slower reaction time. It's kind of like purposefully having tiny lag, in order to have a faster framerate... but of course we're talking about imperceptibly small fractions of a second. After playing around, though, I found the savings on a 120Hz screen to be so marginal that it wasn't worth it. I guess if it were an expensive function then it might be helpful... but displaying buffs on a screen doesn't take much effort. A computer capable of super-duper-fast refresh rates probably has the processing power to push through it anyways. |
Keep in mind, not everyone is running bleeding edge hardware nor can afford to.
|
All times are GMT -6. The time now is 10:42 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI