Did you try disabling this? It’s not enabled by default so must have been enabled manually at some point.
There are some extensions bundled with LibreOffice and will have small padlock icons on the far right - you won’t be able to disable these and that’s fine. They shouldn’t affect this issue.
I disabled “force skia software rendering” and nothing changed. It was still slow and other aspects of libreoffice slowed down as well.
Does this delay only occur once after update, or is it every time you select a filter dropdown?
It occurs every time I click the filter dropdown.
It has been happening to me since the last upgrade, to 24.2.5.2.
150 columns, 65 rows.
I believe it has something to do with the feature of filtering by colour. Is it possible to disable it?
It takes like 4 seconds to open the filter window… which I do a lot.
The problem is in your file - the autofilter area extends to the last row of the sheet (1048576 instead of 10).
Try the corrected version.
TEXAMPLE.ods (15.1 KB)
Thank you, but that file has no auto-filter. And I tried to select only 10 rows, auto-filter, and it takes up to 4 seconds to open the filter dialog.
Could you please check my file, not yours?
There are problems with your specific file.
The TEXAMPLE_2 sheet in your file (from message #10) contains the autofilter which area is A1:IF1048576.
Accordingly, when changing the autofilter, the program scans more than 1,000,000 cells.
Here is a fragment of the content.xml file from the .ods archive:
<table:database-range table:name="__Anonymous_Sheet_DB__0" table:target-range-address="TEXAMPLE_2.A1:TEXAMPLE_2.IF1048576" table:display-filter-buttons="true">
Problem solved.
After realizing that the auto-filter was scanning all rows, I tried several times to disable and re-enable it, limiting it to rows with data, but without success. Here’s what I did:
Cleared all contents from the already supposedly empty cells using “Clear Contents” by selecting all the empty rows.
It’s all working as it should.
Another problem that was nagging me was the slow and sluggish selection of cells.
That is now solved as well.
But, the main problem remains, the same file works fine with the previous versions.
Thank you for your help.
An “unnamed” database range is always created for a sheet filter. This range remains when you remove the autofilter (Ctrl+Shift+L).
When you redefined the filter range, this range was expanded to the maximum again.
This is a bug, but I don’t know how to formulate it clearly yet.
A workaround might be as follows.
Open the file from #10.
Please let me know if this trick helped?
So, here’s the thing, deleting the sheet rows, 12:1048576 won’t solve the problem.
Selecting 12:1048576, and removing all the contents, it will work.
I’ve trying all sort of stuff for a few months, thinking that the problem was in the data, formulas, conditional formatting, etc. Well, it seems not to be.
That’s weird, indeed.
There is still that nasty hidden database range which is created when you do a database operation without defining any range. Meanwhile it is hidden from the API as well.
On top of it all, there are 84 different cell formattings on that sheet, 54 of them i the used area A1:IF10.
Not anymore, thanks to @erAck! 
See GetSheetFilterDBRange.
msgbox GetSheetFilterDBRange(ThisComponent.Sheets(0)).ReferredCells.AbsoluteName
shows $TEXAMPLE_2.$A$1:$IF$1048576 for file from #10.
Innocent users click entire columns before clicking Data>AutoFilter. The result is inacceptable.
Yes, LibreOffice in this case includes all rows of the sheet in the filter (and this is not reasonable in my opinion).
Excel in this case (as far as I know) will limit the filter area to the row for the last “used” cell of the selected columns. “Used” cell: non-empty cell, cell with direct formatting, …
Yet, it isn’t a problem with previous versions, and it’s expected for users to select whole columns for filtering. I’ve up to 700k rows in some sheets and it’s fast opening the filter window.
Just bizarre that “Clear Contents” works for 700001:1048576