QFileDialog with GetOpenFilenames is extremely slow
-
The below code, under Ubuntu Linux 12.04 i386 does 3 seconds to execute:
@QStringList path=QFileDialog::getOpenFileNames(this, tr("Choose Pictures"), QDir::homePath()+"/Pictures", tr("Images")+"(*.png *.gif *.bmp *.jpg *.jpeg *.svg)");@
when I've selected 15 images. That is clearly unacceptable. If I use the QFileDialog::getExistingDirectory function and I loop with my own code through the pictures of the selected directory, then it takes less than 0.5 second to have a QStringList with the 15 images of this specific folder.
The docs suggest to work with a copy of the QStringList when looping through the items, but, of course, this is not the case, here, because I'm not even looping through the items, I just want a QStingList with the selected items, nothing to do with them (yet).
What should be the problem?
-
Is the slow part before the dialog opens, i.e. querying the file system and loading the native dialog or is the slow part after you've accepted/canceled the dialog? Maybe you could do some more fine grained timing. Does it also happen when not using the static function but creating and setting up a QFileDialog step by step?
Further: does the execution time depend on the number of files in the directory and the number of files selected? -
The slow part is when I accept the selected files (aka when I hit the 'Open' button, located at the bottom right of the dialog). Yes, it happens when I'm using the static function, exactly as with the code I provided above. It also occurs when I go with the non-static method:
@QFileDialog dialog;
if(QDir(QDir::homePath()+"/Pictures").exists())
path = dialog.getOpenFileNames(this, tr("Choose Pictures"), QDir::homePath()+"/Pictures", "*png *gif *bmp *jpg *jpeg *svg");@The execution time clearly depends on the number of the selected files.
PS: I am 100% sure that I do not do something further so as to increase the execution time. I have a .ui with a button connected to a slot with only the above code (without processing the selected images), and it is still extremely slow.
PS2: This behavior is reproducable both by me and a friend of mine with Ubuntu 12.04 64-bit.
Thanks for your reply
-
Weird :( I am using Qt 4.8.0 :/
This is a video showing the problem:
http://www.mediafire.com/download.php?a7tvsh52shq4bh5This is the files of this small program on the video:
http://www.mediafire.com/download.php?v5k41xe3naaj5ieIf these help... I strongly suspect that it has to do with the probably one of the image filters I've set?
-
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.
