http://bugs.winehq.org/show_bug.cgi?id=26803
Summary: file open dialog: slow when selecting many files Product: Wine Version: 1.3.17 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: pa78@gmx.net
The bug: The more files I select in the file open diaolg the longer it takes until the files are actually selected and I can click the open button. This bug is not about the load time of the program but the time the files get selected in the file open dialog.
Hints to reproduce: Selecting one file in the dialog window happen instantly. Pressing shift and selecting 3 files also is very fast. Pressing shift and selecting 10 files takes up to 1 second. Pressing shift and selecting 30 files already takes 10 seconds. Pressing shift and selecting 50 files already takes 40 seconds. Pressing shift and selecting 100 files already takes 270 seconds (equals 4:30 min). As you can see times are raising nearly exponential. In Windows/Gnome/Kde/... it doesn't matter how many files are selected/deselected. It takes always the same time.
Additional notes: My cpu is a 3 year old dualcore 1.86 ghz. If you can't reproduce this times because your machine is much faster just select more files because time is raising nearly exponential.
This is an old bug (probably pre wine 1.0) and still (wine 1.3.17) very annoying to me because sometimes I have to open a few hundret files. I think this was never implemented well. Just so far that it is possible to open one or a few files.
http://bugs.winehq.org/show_bug.cgi?id=26803
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #1 from Ken Sharp kennybobs@o2.co.uk 2011-04-17 08:35:58 CDT --- Using what app?
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #2 from Paul Romanyszyn pgr@arcelectronicsinc.com 2011-04-18 23:13:42 CDT --- I have notices the very slow select a long time ago using registax4 from http://www.astronomie.be/registax/download.html I found a workaround using drag and drop. I just tested with a new install of registax 6 and it is slow. With this program the file dialog has a image preview. It appears that every time the file list edit box had an item appended the dialog does a paint refresh.
I don't have a windows machine to check how slow it is on windows but as I recall running 98 or XP under qemu was much faster.
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com 2011-04-18 23:23:35 CDT --- Does native comctl32 help? If it does I think I know where this slowdown comes from (we might have a report for that in comctl32 section). When you select a new file it probably sorts whole list again and again to update selection for example. Some years ago selection handling was broken - it wasn't properly updated when you sort a list, I fixed selection and it's probably a reason.
http://bugs.winehq.org/show_bug.cgi?id=26803
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, performance Status|UNCONFIRMED |NEW URL| |http://www.rarlab.com/rar/w | |rar400.exe CC| |kennybobs@o2.co.uk Ever Confirmed|0 |1
--- Comment #4 from Ken Sharp kennybobs@o2.co.uk 2011-04-18 23:43:20 CDT --- Confirming. Also apparent when selecting files to add in WinRAR.
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #5 from Ken Sharp kennybobs@o2.co.uk 2011-04-18 23:50:24 CDT --- Native comctl32 does not help.
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #6 from Ken Sharp kennybobs@o2.co.uk 2011-04-18 23:58:16 CDT --- In WinRAR's case, the whole output is:
fixme:heap:HeapSetInformation 0x2c4000 0 0x23fc20 4 fixme:shell:SHAutoComplete stub err:listview:LISTVIEW_WindowProc unknown msg 108c wp=00000000 lp=00000000 fixme:shell:SHAutoComplete stub fixme:commdlg:GetFileName95 Flags 0x00010000 not yet implemented fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000090 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010
http://bugs.winehq.org/show_bug.cgi?id=26803
Jonas Nyrén jonas.nyren@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.nyren@gmail.com
--- Comment #7 from Jonas Nyrén jonas.nyren@gmail.com 2011-06-13 17:11:48 CDT --- Confirming. Happens in foobar2000 aswell when shift-selecting. Anything above ~10 files is unbearably slow.
http://bugs.winehq.org/show_bug.cgi?id=26803
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #8 from Ken Sharp kennybobs@o2.co.uk 2012-06-27 01:06:13 CDT --- Still present in wine-1.5.7-114-gd079b66
http://bugs.winehq.org/show_bug.cgi?id=26803
Daniel Jelinski djelinski1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djelinski1@gmail.com
--- Comment #9 from Daniel Jelinski djelinski1@gmail.com 2013-05-21 15:30:44 CDT --- The slow function is FILEDLG95_FILENAME_FillFromSelection. Commenting out the following line is enough to bring the selection back to normal speed: http://source.winehq.org/git/wine.git/blob/c34baac0cbb9e5fb86898cbf015c6183b... Unfortunately dialogs stop working with that line commented. Any volunteers to optimize that function?
https://bugs.winehq.org/show_bug.cgi?id=26803
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |comdlg32
https://bugs.winehq.org/show_bug.cgi?id=26803
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #10 from super_man@post.com --- (In reply to Daniel Jelinski from comment #9)
The slow function is FILEDLG95_FILENAME_FillFromSelection. Commenting out the following line is enough to bring the selection back to normal speed: http://source.winehq.org/git/wine.git/blob/ c34baac0cbb9e5fb86898cbf015c6183b70cf90a:/dlls/comdlg32/filedlgbrowser.c#l818 Unfortunately dialogs stop working with that line commented. Any volunteers to optimize that function?
Most likely the problem is somewhere here.
http://source.winehq.org/git/wine.git/blob/c34baac0cbb9e5fb86898cbf015c6183b...
It's quite interesting to read that source.
https://bugs.winehq.org/show_bug.cgi?id=26803
Lauri Kenttä lauri.kentta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lauri.kentta@gmail.com
--- Comment #11 from Lauri Kenttä lauri.kentta@gmail.com --- Created attachment 54831 --> https://bugs.winehq.org/attachment.cgi?id=54831 Test case
The problem is not program-dependent. The attached program just creates 1000 files (in a directory) and shows the file open dialog. You can easily observe how the selection becomes slower the more files you select.
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #12 from Lauri Kenttä lauri.kentta@gmail.com --- I had a closer look at this.
FILEDLG95_FILENAME_FillFromSelection is somewhat poorly implemented, it loops the files twice, calls GlobalLock many times etc. Still, fixing this function improves speed only by 30% for 250 files (depends on the number of files).
Commenting out SetWindowTextW in FILEDLG95_FILENAME_FillFromSelection makes the selection a lot faster, but clearly this is not a valid solution.
The real problem seems to be that the list is updated for each selected file, even if multiple files are selected at once (try shift+end, for example). These calls come from line 1443 in shell32/shlview.c (LVN_ITEMCHANGED, OnStateChange).
There should be some way to defer FILEDLG95_FILENAME_FillFromSelection (or at least SetWindowTextW) until all the files have been selected.
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #13 from super_man@post.com --- I have no idea how it works, but based on your analyze I think the correct way to do the calls is only when the button open is pressed then it would "validate" the selected file(s).
I don't know if its possible. It doesnt make sense to everytime a file is selected, but not opened make a some system call.
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Lauri Kenttä from comment #12)
I had a closer look at this.
FILEDLG95_FILENAME_FillFromSelection is somewhat poorly implemented, it loops the files twice, calls GlobalLock many times etc. Still, fixing this function improves speed only by 30% for 250 files (depends on the number of files).
That sounds like a pretty good start, please send these improving patches.
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #15 from Lauri Kenttä lauri.kentta@gmail.com --- (In reply to super_man from comment #13)
I have no idea how it works, but based on your analyze I think the correct way to do the calls is only when the button open is pressed then it would "validate" the selected file(s).
That's not an option. The selected file names are shown (real-time) in the edit box below the explorer view, and I don't think we can just remove that edit box.
(In reply to Bruno Jesus from comment #14)
(In reply to Lauri Kenttä from comment #12)
improves speed only by 30% for 250 files
That sounds like a pretty good start, please send these improving patches.
Will do. However, the reason why I think these optimizations are (or should be) irrelevant is that a proper fix would drop this from tens of seconds to something like 0,1 seconds.
https://bugs.winehq.org/show_bug.cgi?id=26803
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #16 from winetest@luukku.com --- Can we consider this bug as fixed? The patches you sent were merged.
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #17 from Lauri Kenttä lauri.kentta@gmail.com --- (In reply to winetest from comment #16)
Can we consider this bug as fixed? The patches you sent were merged.
Not fixed. As noted previously, my patches are only a minor speedup, whereas the action should really be instantaneous. I'll see if there's any easy way to improve shell32/comdlg32 to handle the whole process better.
https://bugs.winehq.org/show_bug.cgi?id=26803
donanykey@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |donanykey@gmail.com
--- Comment #18 from donanykey@gmail.com --- Confirmed wine-devel 3.17
Even though its not that dramatic as in the initial message, still, 823 files are being selected in ~7 seconds, while on Windows 10 -- 4366 files in ~2 seconds
C:\windows\system32 was used for both selections
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- No change in Wine 4.18
https://bugs.winehq.org/show_bug.cgi?id=26803
--- Comment #20 from Artem S. Tashkinov aros@gmx.com --- Selecting 560 files takes around 5 seconds on the Ryzen 7 3700X CPU with Wine 5.20.
I guess it could be further improved but it's nowhere as bad as originally reported.