Hey Chip, thanks again for all the discussion, I really appreciate the insight.
Originally Posted by ZOS_ChipHilseberg
Here is an example:
Lua Code:
control:AddFilterForEvent(EVENT_POWER_UPDATE, REGISTER_FILTER_UNIT_TAG_PREFIX, "boss")
The advantage is that we can filter very cheaply in C++ and we don't have to pay the price of going into the VM only for it to early out.
We can look into it. Are there any other examples you have? |
Very interesting. So, in the POWER_UPDATE example, if I'm understanding this correctly: if we are doing unit frames, and we have several different controls (player, target, group, boss, etc..) it would be "best practice" in 1.7+ to :RegisterForEvent() each control separately, and :AddFilterForEvent() each control for its relevant unit tag prefix.
Hopefully the 1.7 API documentation can have a list of allowable filters per event, but this sounds promising for both addons and default UI. Do you guys already use these filters, or is this a new logic that will benefit the default UI as well?
I have a more "big-picture" question, if you can indulge me. Suppose 10 controls all register for a certain event. When the event-triggering action occurs, does C++ issue 10 parallel calls to the LUA VM, or does it just send the event to LUA which distributes it to the 10 registered controls? It sounds to me like what you are saying is that the C-side filtering would allow us to reduce the number of calls to the VM, so I'm guessing it's parallel threads. Given the amount of filtering that I do in FTC alone I could easily see how this could have a performance impact. I filter out maybe 7/10 events that I am registered for.
Originally Posted by ZOS_ChipHilseberg
For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.
|
Sounds super helpful, I hope this can happen!