Search…

X3 Photo Gallery Support Forums

Search…
 
User avatar
sHagen
Topic Author
Posts: 19
Joined: 13 Aug 2016, 19:02

filter input debounce

01 Jan 2021, 07:55

Hi,

thanks a ton for the files app. I'm using it in my intranet to make my file server more enjoyable to browse.
I noticed that the search on the top left does this "search as you type" thing. In a folder with many files, this can be pretty slow.

I have a folder with 6000 files. If I search for "alex", it goes like this:

"a"<4 seconds, 4k hits>
"al"<1 second, 700 hits>
"ale"<almost instant, 40 hits>

When deleting the search term via backspace it takes those combined 5+ seconds again. On less powerful CPUs it takes a lot longer.

Would it be possbible to allow us to deactivate this and search on hitting return?
Or to introduce a delay so the search is triggered after 1 second without keypress?
Or start searching on the third character?

Best Regards,
Stefan
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13993
Joined: 30 Sep 2006, 03:37

Re: Files app 0.2.0 :apple:

02 Jan 2021, 00:44

sHagen wrote:In a folder with many files, this can be pretty slow.

I have a folder with 6000 files. If I search for "alex", it goes like this:

"a"<4 seconds, 4k hits>
"al"<1 second, 700 hits>
"ale"<almost instant, 40 hits>
Indeed that could be slow. As you may understand, the reason it get progressively faster is because there are less items to search and less items to re-order (on screen) once the search narrows down.
sHagen wrote:When deleting the search term via backspace it takes those combined 5+ seconds again. On less powerful CPUs it takes a lot longer.
Yes that would be expected behavior in reverse.
sHagen wrote:Would it be possbible to allow us to deactivate this and search on hitting return?
Or to introduce a delay so the search is triggered after 1 second without keypress?
Or start searching on the third character?
Some good ideas here ... Exactly what I had in mind in fact. It's not unusual to start searching from minimum three characters (little chance anyone is searching files with a single character) and that should perhaps be a new default. I think also we could have options for search on keypress-timeout and search on return keypress (+ search button). It could also be an idea implement behavior based on the amount of files in the folder ... For example, if there are less than 100 files, it really doesn't hurt to have instant search.

FYI: I think the reason for long delays isn't the search itself, but re-sorting thousands of DOM elements in the browser on keypress.

I'll look into this for next release, which will get started in a few weeks. Thanks for posting!
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13993
Joined: 30 Sep 2006, 03:37

Re: filter input debounce

21 Aug 2021, 03:30

I split @sHagen's post from the Files app 0.2.0 releast post into a new topic, as it's an important request. Considering the issues in the original post, I have now spent time optimizing filter input for the forthcoming Files app 0.3.0 release. Below I have highlighted changes to filtering:

:heavy_check_mark: Live input filter debounce [250 - 750 ms]
Most importantly, there is now a "debounce" on keyboard input, which delays the filter from processing until 250 ms (0.25 seconds) has passed without keyboard input. Technically, this means that as a user inputs "abc", the filter may trigger only once (after "abc") instead of unnecessarily triggering with "a", "ab" and "abc".  
As the amount of files in the list increases, the debounce delay will increase up to 750 ms (0.75 seconds) to minimize unnecessary filtering in larger lists. The delay (in milliseconds) is proportional to the amount of files, but set at minimum 250 ms (< 250 files) and maximum 750 ms (>750 files). With a minimum 250 ms debounce, filter input still feels instant, while minimizing unnecessary processing and "layout thrashing" also on small lists. Upper limit 750 ms still feels sufficiently snappy, but borders on the maximum time user is willing to wait for instant input filtering to remain satisfying and useful. Debounce values > 750 ms seem pointless, as the delay will compound with the delay of the actual filter process, making "instant input filter" unintutive and unproductive. In such case, it would be better to instead disable the new filter_live option entirely.

:heavy_check_mark: Live input filter DISABLED on MOBILE
After much testing, I decided to disable live input filtering on mobile devices. Instead, mobile devices will filter on SEARCH/DONE/CLOSE from the mobile popup keyboard that appears on screen. This was an easy choice, considering mobile devices may struggle with live input filtering caused by relatively slow keyboard input and less powerful CPU. Besides, it's more intuitive to filter from the "search" or "done" buttons that appear in the keyboard on mobile devices. 
Furthermore, since the keyboard often covers upto half the screen on mobile devices, live input filtering is less useful anyway. 

:heavy_check_mark: New [filter_live] option
If live input filter seems ineffective and/or you have massive folders, you might consider disabling it by setting the filter_live option to false. When disabled, filter will only trigger on keyboard RETURN or input field BLUR (tabbing or clicking away from the filter input). This allows the filter to trigger only once initiated by the user.


:no_entry_sign: Minimum character input
I originally did some testing with "minimum character input", which would logically be set to something like "3". However, I found that this feature was a bit clumsy when combined with live input. For example, when inputting "ab" nothing happens, until I add a third character "abc" and a filter results suddenly appear. Then I BACKSPACE to "ab" and the entire filter has to be removed again (so technically, it would need to re-filter anyway) ... of course, we can't suddenly show filter results for "ab" just because we removed a character. Furthermore, one would need to notify the visitor somehow that a minimum amount of chars is required to trigger the filter, while some users may want to filter for file types or numbering like "01" or "jp".
 In conclusion, this feature seems pointless when there is an option to disable filter_live.

:heavy_check_mark: New [filter_props] option
New filter_props option allows you to assign what features to filter from, with default values 'name, filetype, mime, features'. The less properties, the faster the filter, although it doesn't seem to have too much impact on performance.


Performance notes
In conslusion, the above features hould make filtering more effective to use across all devices. 
Keep in mind, once a filter does trigger, it will take as much time as the system (CPU) requires to render the result from the amount of items in the list.

Looking forward to Files app 0.3.0!
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13993
Joined: 30 Sep 2006, 03:37

Re: filter input debounce

08 Nov 2021, 05:21

Files App 0.3.0 now debounces keyboard input to prevent premature search "thrashing". See demo