QFileDialog with GetOpenFilenames is extremely slow
-
This is just a BUMP
-
Might have to do with filling in the path variable from the QFileDialog. If i may ask, but why don't you use the static QFileDialog option?
@QStringList path = QFileDialog::getOpenFileNames(.....);@
That probably doesn't change anything, but still is a bit shorter and voids the use of a local variable.
I think that selecting a lot of pictures slows things down, but you thought of it yourself.
greetz -
[quote author="Jeroentje@home" date="1346833815"]Might have to do with filling in the path variable from the QFileDialog.[/quote] Appending fifteen small-sized strings? Not a chance.
[quote author="Jeroentje@home" date="1346833815"]but why don't you use the static QFileDialog option?
QStringList path = QFileDialog::getOpenFileNames(.....);
That probably doesn't change anything, but still is a bit shorter and voids the use of a local variable.[/quote]
He does, as you can see in the very first post.
[quote author="Jeroentje@home" date="1346833815"]I think that selecting a lot of pictures slows things down[/quote] No it doesn't because then I could reproduce it. We're talking about 15 Pictures by the way, not "a lot". That would be 15.000 pictures.It must be some strange interference between the Qt you're using and your system(s). What's even stranger is that you seem to be able to reproduce it on multiple systems while I wasn't, also on multiple (linux and windows) systems.
Maybe you can upload the entire application with a working test case. -
[quote author="DerManu" date="1346839014"]
Maybe you can upload the entire application with a working test case.
[/quote]I did so, see the mediafire links above. I provide you with a video and right after with the files I used so as to compile the application I used on the video...
-
[quote author="alexandros" date="1346843765"]
I did so, see the mediafire links above. I provide you with a video and right after with the files I used so as to compile the application I used on the video...
[/quote]Yes, that's the project I used to try to reproduce the problem but couldn't. But that's not your real application, is it?
But you're right actually, If this small project already shows the problem on your system, it should be enough.
One last idea: Find a way to step into Qt in debug mode. I haven't done that before, you might need to compile Qt yourself in debug mode. this way you can step all the way through the slow process and identify the commands that take so long. If this works, you can file an appropriate bug (possibly with fix) in the Qt bug tracker. -
What I find extremely weird is the fact that I can reproduce it both in a 32-bit system and in a 64-bit system. Usually, when something like this is reproducale in both systems then it is something like a rule. I will see if there's something wrong with my files, and if I have no luck, then I will try your suggestion...
-
I too am seeing this behavior. I did some testing and found that the call to getOpenFileNames returns almost immediately, with the correct list of file names, but then at some later point the program hangs while the open file dialog is still visible. It must be something about closing the window / destructing some data structures? As with the other reports, it hangs for a time that scales with the number of files selected and is very, very long (long enough that I force-quit) for e.g. 100 images selected. I am also selecting image files; perhaps that is relevant?
-
I can reproduce this under windows 8.1 using qt 4.8.5.
QFileDialog::getExistingDirectory(this, "Select Folder.", qApp->applicationDirPath()));
This call is used, an the gui isn't responding after a folder is selected but before the dialog is closed. What's weird is, it doesn't always block, sometimes it runs just fine.
