[Bug 26803] New: file open dialog: slow when selecting many files
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(a)winehq.org ReportedBy: pa78(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #1 from Ken Sharp <kennybobs(a)o2.co.uk> 2011-04-17 08:35:58 CDT --- Using what app? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #2 from Paul Romanyszyn <pgr(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #3 from Nikolay Sivov <bunglehead(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 Ken Sharp <kennybobs(a)o2.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, performance Status|UNCONFIRMED |NEW URL| |http://www.rarlab.com/rar/w | |rar400.exe CC| |kennybobs(a)o2.co.uk Ever Confirmed|0 |1 --- Comment #4 from Ken Sharp <kennybobs(a)o2.co.uk> 2011-04-18 23:43:20 CDT --- Confirming. Also apparent when selecting files to add in WinRAR. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #5 from Ken Sharp <kennybobs(a)o2.co.uk> 2011-04-18 23:50:24 CDT --- Native comctl32 does not help. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #6 from Ken Sharp <kennybobs(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 Jonas Nyrén <jonas.nyren(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.nyren(a)gmail.com --- Comment #7 from Jonas Nyrén <jonas.nyren(a)gmail.com> 2011-06-13 17:11:48 CDT --- Confirming. Happens in foobar2000 aswell when shift-selecting. Anything above ~10 files is unbearably slow. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 fracting <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #8 from Ken Sharp <kennybobs(a)o2.co.uk> 2012-06-27 01:06:13 CDT --- Still present in wine-1.5.7-114-gd079b66 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26803 Daniel Jelinski <djelinski1(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djelinski1(a)gmail.com --- Comment #9 from Daniel Jelinski <djelinski1(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |comdlg32 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 super_man(a)post.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man(a)post.com --- Comment #10 from super_man(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 Lauri Kenttä <lauri.kentta(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lauri.kentta(a)gmail.com --- Comment #11 from Lauri Kenttä <lauri.kentta(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #12 from Lauri Kenttä <lauri.kentta(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #13 from super_man(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #14 from Bruno Jesus <00cpxxx(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #15 from Lauri Kenttä <lauri.kentta(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #16 from winetest(a)luukku.com --- Can we consider this bug as fixed? The patches you sent were merged. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #17 from Lauri Kenttä <lauri.kentta(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 donanykey(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |donanykey(a)gmail.com --- Comment #18 from donanykey(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #19 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- No change in Wine 4.18 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26803 --- Comment #20 from Artem S. Tashkinov <aros(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla