Just my thoughts about it, without having feedback for the performance differences between option a) and b) :
I'd choose option B) to only register the filters needed at the current panel (vendor, trade, mail, etc.).
You can see if the current panel is opened by checking the following constants (not a complete list):
Lua Code:
local BACKPACK = ZO_PlayerInventoryBackpack
local BANK = ZO_PlayerBankBackpack
local GUILD_BANK = ZO_GuildBankBackpack
local DECONSTRUCTION = ZO_SmithingTopLevelDeconstructionPanelInventoryBackpack
local IMPROVEMENT = ZO_SmithingTopLevelImprovementPanelInventoryBackpack
local MAIL_SEND = ZO_MailSend
local PLAYER_TRADING = ZO_Trade
local ENCHANTING_STATION = ZO_EnchantingTopLevelInventoryBackpack
local VENDOR_SELL = ZO_StoreWindowListSellToVendorArea
e.g. if you click the button, or change the dropdown of AdvancedFilters, check if one of the ZO_ variables is currently visible:
Lua Code:
--See if we are sending a mail
if (not MAIL_SEND:IsHidden()) then
-- register additional filter for LAF_MAIL
elseif (not PLAYER_TRADING:IsHidden()) then
-- register additional filter for LAF_TRADE
...
end
Avoid registering the filters twice by checking if the filter is already registered libfilters:IsFilterRegistered(filterId) in advance
(btw: wouldn't this even make sense to be added inside the libfilters:registerFilter function by default?)
I'm not sure if the button's OnClicked or the dropdown's OnSelectItem is the best position to check this.
I bet this is less performance consumting then always enabling the LAF_BAGS filters too, which would result in another check (callback function for the filter) for all inventory items.
Originally Posted by Randactyl
Yeah I noticed that as well. I'm working right now on making Advanced Filters behave responsibly - I think making it use the correct filters for the correct layouts is the way to go.
Edit: actually, it's really the "same inventory" in any of those contextual fragments just with special flavor like a label saying "Sell" instead of "Inventory" and the buttons to navigate through that fragment, right?
Kinda just thinking out loud here:
So then we would want to include all of the LAF_BAGS filters by default? (at least for Advanced Filters, anyway)
I'm trying to think of when I would want different filters in Sell vs. Mail vs. Inventory.
I don't think it would be good to always register/unregister filters for every scene type.
Option B could involve something like me choosing the correct LAF by hooking the display of a scene just like libFilters uses to determine which LAF to apply.
Option A sounds to be the easiest, but I have a gut feeling that is not the best thing to do.
I'm hesitant to dive into these changes because I'm trying to figure out which would be the best option performance wise since that is what all of this discussion was borne out of. I just don't know enough about performance impacts of the different options to make a call out of the gate.
|