View Single Post
11/24/14, 01:24 PM   #13
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 5,033
I tried this zo_callLater workaround with 500ms. It is annoying as the filters won#t update after the click, but half a second later.
It seems to bring a way better performance as you switch tabs in inventories.
But only as long as you do not enable all FCOItemSaver filters (4 possible) in the inventories.
If all 4 filters are enabled each click will last for about 3 seconds again before something happens

So using the updateFlag variable is not a working workaround alone. It seems the behaviour of AdvancedFilters needs to be fixed too.



Originally Posted by circonian View Post
Ok, couldn't sleep so had some more time to look at it, here is "A" problem I see. This seems to be the one causing the most lag.
A zillion edits, sorry I hate type-o's and grammar mistakes and I make tons of them.

The problem is with libFilters

In this click of a single inventory tab libFilters runs all of this:

Side note: Edit: See my next post about Advanced Filters on this problem. I didn't dig this deep into it, there may be a reason, but you might also want to look at: Why is libFilters Unregistering AdvancedFilters_Dropdown_fitler twice in a row, then registering it, then unregistering it again, then registering it again ? It also shows the AdvancedFilters_Button_Filter being unregistered twice in a row, then reregistered?

All of that is in a single click of an inventory tab and those are supposed to be unique filter ID's are they not? so it has to be the same thing its unregistering & registering multiple times correct?
The main problem is updating the filter list after every single register & unregister event. It processes every single slot like 20-30 ?more? times (I got tired of counting them) in the click of a single button. If even more addons were using this or you guys were registering multiple (more) filters it would probably crash users instantly.
I'm not sure why everything is registered & unregistered all of the time....why aren't filters just registered, left in a table & called when needed...
Anyhow It can be fixed doing this (not saying its ideal, I'm no expert here)

The main idea would be to just zo_calllater the UpdateFilteredList() and put a lock on it..
So set a flag, I called it updateSet (as in the update is set to process), when its true a zo_calllater has already been made for the UpdateFilteredList() to run after however long.
This gives all filters a chance to register/unregister before it runs. So that UpdateFilteredList() only needs to run once.


First make a new local variable for our lock flag in libFilters:
Lua Code:
  1. local updateSet = false
That tells us whether or not an UpdateFilteredList(..) has already been called with a zo_calllater (to run sometime in the future). This way if the lock flag is already set, we wont keep calling UpdateFilteredList() over & over for no reason. You probably want to adjust the time, i put 500 in there just as a random number to test it, thats probably to long.


Changes: function libFilters:RegisterFilter( filterId, filterType, filterCallback )
Warning: Spoiler



Changes: function libFilters:UnregisterFilter( filterId )
Warning: Spoiler


** Do note I would make sure you call
Lua Code:
  1. -- This line
  2. updateSet = false
  3. -- before calling this line
  4. UpdateFilteredList(filterType)
This way if something has already called RegisterFilter or UnRegisterFilter while the UpdateFilteredList is running...the new register/unregister event will have a chance to call another zo_calllater'd UpdateFilteredList because it will miss the....UpdateFilteredList that is already in progress.

If you called updateSet = false after calling UpdateFilteredList() something could slip through the cracks.
wow...I hope that made sense :P

P.S. And don't forget, this should be local !
Lua Code:
  1. -- in libfilters.lua
  2. -- this should be local
  3. filters = libFilters.filters
  Reply With Quote