Improvement to GoToWindow Expend Browser Tabs Brower Tab performance

[royharoush]

Hi Guys,
Really cool project, and the Expend browser tabs is a must have feature for every proper launcher\window manager.
I disussed your project on the powertoys project, and suggested a fix which i'll be very happy if you consider in the expend browser tabs" plugin.
I sorta detail it in this comment microsoft/PowerToys#1912 (comment)
Essentially what I think is that tab expansion would be much faster if we store tabs periodically into memory and pull from there, instead of expending using objects each time the user opens the UI.
Would love to hear your thoughts !
Thanks,
Roy

[christianrondeau]

Hi! Yeah I agree that it's sluggish and would be happy if there is a better approach. I already implemented something similar for listening to wmi events (when running as an administrator) so the list, titles and icons are readily available as soon as the user presses alt tab.

I'm not sure about polling though.

1. If it's slow, it's because it's resource intensive (somewhat) so having the tabbing tool consume resources while unused is not great, unless it's really small.
2. Probably more important, it means if you open a tab and tab to it immediately you might miss the event. I tried populating as tabs data were available but it's not fun to use as the list changes unexpectedly.

Do you see a way to achieve this while mitigating those problems? I will gladly take a PR if you have an idea in mind! (or make it an option).

I should probably update the csproj format though (unrelated).

[royharoush]

Thank you for the willingness !
I think that we don't have to poll\pull the entire tab list every x internal. Your idea of listening to WMI events is interesting , but im not familiar with WMI event created when tabs are created. it will be interesting to try.

I have two approaches in mind:

1. I thought that perhaps the rendering time (and maybe a sorting operation) is also resource consuming, so upon getting the list the first time the plugin can hash the result set, and while pulling the plugin will compare the hashes (from the current state and last pull) and check if they are matched, if they don't, the plugin can use the list still in memory and diff it to add it to the tab list. we can also make the ui load a little sluggish if we don't wait for the list to load and display it asynchronously, this might add some resource consumption, but from testing 3 chrome profiles and firefox with around 80 tabs opened overall, it takes around 3 seconds to load (obviously, depends on the hardware), with a few hundreds of bytes disk IO and very little memory and swap footprint (around 10mb of memory). the cpu cycle seems to cap at around 5-10% for 3 seconds, which should be ok on most processors.
   to summarize, cache the results in memory, hash and diff them periodically every X seconds (perhaps it can be configurable by the user), and display results without waiting for the next hash\diff operation.

2. Another approach would be to Integrate with an existing (or a new) browser extension that is able to list all tabs without using ui automation. some examples are quick tabs(https://chrome.google.com/webstore/detail/quick-tabs/jnjfeinjfmenlddahdjdmgpbokiacbbb) and tab manager plus( https://chrome.google.com/webstore/detail/tab-manager-plus-for-chro/cnkdjjdmfiffagllbiiilooaoofcoeff), both are cross platform browser(chrome\ium\edgium and firefox.
   if you decide to go with a new extension in chrome there's an API in chrome that allows you to talk with a nativeApp. here's some information about it.

https://stackoverflow.com/questions/26582584/chrome-native-host-in-c-cannot-communicate-with-chrome
https://developer.chrome.com/apps/nativeMessaging

I hope all of that makes sense.
wdyt ?

[christianrondeau]

Well to compare the hash you need to check for tabs, which brings us back to either waiting for the up to date tabs v.s. dynamically changing the list. This being said I'm not against it if it's optional (and most of the time you will have the right tabs so it's fine).

If it's possible to bypass the automation API, it would be definitely better! Edge now supports native alt-tabbing so that might have become a no-issue, support for IE is probably unnecessary. The Chrome extension sounds good in theory if it works!

[royharoush]

the point im making is that if you don't have the ui wait for the list to reload everytime and keep it in memory, you will not feel the slugishness when you open the UI.
we don't open tabs every 10 seconds (ok... maybe some of us do ..) but usually the list of tabs is pretty static, and if we keep updating it in a different thread and not wait for it to load, the experience should be faster.

[christianrondeau]

Yeah, I understand and it makes sense. I think snappy response times are highly desirable, and correctness is highly desirable too. There's probably a balance in between but no "right" answer. Same for resources usage, right now (as you can see from the lack of recent commits) I'm highly invested in other projects so I can't validate how expensive tabs scanning is, but in the end this can all be tweaked. Scan every 10 seconds or every minute in a setting, potentially show that "more up to date results are available" in the UI for the rare cases where you might tab too fast, would probably work fine. In other words, I'm perfectly fine with your proposed approach. If I want to tab to something and I cannot find it, but scanning is "fast enough" (e.g. 1-2 seconds) and I can see that my result is "out of date" but I still have immediate access to the listing, I believe it provides a pretty good balance.