Description: Autofilter drop down opens with a delay (with multiple filter criteria set) Steps to Reproduce: 1. Open the attached file 2. Press the drop down button for column E (or any other column) Actual Results: 3 seconds delay Expected Results: Instand Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta1+ Build ID: c344de1b9985b6ca10b354e24151d0bdf92dc20e CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and in 5.0
Created attachment 161814 [details] Example file
Created attachment 161815 [details] Bibisect log 2007907198b079a0c488cd7e70f9191fcb0145d9 is the first bad commit commit 2007907198b079a0c488cd7e70f9191fcb0145d9 Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 17:20:54 2015 +0800 source-hash-b500e60b32b5cf8fd61beb7476c2c29e65aee3e4 commit b500e60b32b5cf8fd61beb7476c2c29e65aee3e4 Author: Eike Rathke <erack@redhat.com> AuthorDate: Fri Dec 12 14:49:09 2014 +0100 Commit: Eike Rathke <erack@redhat.com> CommitDate: Fri Dec 12 15:22:43 2014 +0100 resolved fdo#86809 connect filter conditions correctly Maybe since 0960ec3e1b7b0d872d1f84d2d56f480a4df08b21 all conditions of a single filter stack were OR connected, regardless whether filter-and was given in the file. Change-Id: Ifb423ccc7deb42bb6bba0bfc810607633f2c342c :040000 040000 2d8ad128a0ab469451f5f250612fc4ef6db5a9a4 a0cbf75824bbd5d1a4911ffd511bdca99e6a6a21 M opt https://cgit.freedesktop.org/libreoffice/core/commit/?id=b500e60b32b5cf8fd61beb7476c2c29e65aee3e4
And/OR was broken 'on file opening' prior to this commit, but could re-instated by resetting the filters etc. Speed for drop was always fine. Likely the ++rItem.mnCondCount; is happening 'on click' the drop down
Version: 6.4.4.2 (x64) Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL Opening the attached sample file with 40,000 rows, and autofilter set on 5 of the columns. Selecting the autofilter drop button, I see a delay ~3 sec--but I am not sure that is incorrect. Logical AND for the 5 columns has to take some time for filter to parse out rows. And as I reduce the number of autofiltered columns the Sort and filter listbox completes its load faster. Improving with each reduction in column filter as I'd expect. Is this actually an issue?
(In reply to V Stuart Foote from comment #4) > Version: 6.4.4.2 (x64) > Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff > CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; > Locale: en-US (en_US); UI-Language: en-US > Calc: CL > > Opening the attached sample file with 40,000 rows, and autofilter set on 5 > of the columns. > > Selecting the autofilter drop button, I see a delay ~3 sec--but I am not > sure that is incorrect. > > Logical AND for the 5 columns has to take some time for filter to parse out > rows. And as I reduce the number of autofiltered columns the Sort and > filter listbox completes its load faster. Improving with each reduction in > column filter as I'd expect. > > Is this actually an issue? If you're filtering out something.. the point is.. , it was more optimal. Same case, same situation.. Is major no. Influences user experience. Yes
there is a lag, not dramatic but it is, is it neccessary? when opening the autofilter dialog for a new column somewhere is a matrix(?) with the info which rows are to be displayed / hidden, you need not work through all columns all items and combine them to produce the autofilter list (as proposed in c#4), just get the 'open' possibilities for this column - less than 40.000, and produce a sorted de-duplicated list, imho that can work faster ... btw. it looks as it's not possible or not implemented to sync autofilter definition to 'standard filter' ... thus switching to standard filter after autofilter sort criteria are set produces crap,
This is now fixed on master by: ommit 2e0d5203b0b8133ebc2e6f90c0e0a24962f144f2 Author: Luboš Luňák <l.lunak@collabora.com> Date: Tue Nov 23 13:35:58 2021 +0100 do not wait for condition that's not needed When not querying for the test equal condition, it's pointless to keep searching for it to become true only to throw it away. Change-Id: Ie861bac141f80025e95753fb8b1202498df17383 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125733 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Actually this is a part of a series of auto filter related improvements these days done by Luboš Luňák, Noel Grandin and others. Please test with a daily build after 2021-11-26 to see if there are regressions.