Page MenuHome

File Browser is unusable on Windows Machines
Closed, ResolvedPublic


System Information
Windows 7 x64, gtx 580

Blender Version
Broken: 2.73-c439d14
Worked: 2.73-4ae6d58

Short description of error
File browser (file open / file save) is unusable under windows 7 x64.

Exact steps for others to reproduce the error

  1. Go onto a windows computer
  2. try saving as
  3. wait 10-15 seconds for it to load the current directory
  4. try changing directories and notice you get 1 frame update every 5 seconds (hover highlight and what not), makes changing directories / which file to load very hard.

Event Timeline

Bastien Montagne (mont29) claimed this task.
Bastien Montagne (mont29) triaged this task as Normal priority.

Did some changes in this area yesterday… would not have expected anything new (was mostly cleaning), but looks like windows thinks differently once again. :/

I tested it on my machine and can't reproduce the problem, everything works fine and is responsive in the file browser. I used the same blender-2.73-c439d14-win64 build, also on Win 7 64, mobility radeon 5650.

Also, changing interface draw methods didn't change anything, it was still responsive.

@Matjaž Lamut (lamoot) thanks for the feedback.

This report really is odd, but was reported separately by two people, so there must be something fishy going on here. Checking currently on my windows VM (building blender on win takes ages…), could also be related to recent OpenGL commit (and drivers, of course). ;)

Bastien Montagne (mont29) lowered the priority of this task from Normal to Needs Information from User.Feb 16 2015, 1:07 PM

Yeah… cannot confirm that here either (VM, so using softwaregl)…

@Carlo Andreacchio (candreacchio) & @Ulysse Martin (youle) can you please:

  • Ensure both your OS and drivers are fully up-to-date.
  • Ensure your GPU driver supports at least OpenGL 1.4.
  • Try to start Blender in factory settings (--factory-startup commandline option) (this will ensure whether this is a userpref or addon issue or not).
  • Try to tweak OGL settings in UserPreferences, System tab.
  • Attach here the report generated by Help -> System Info.
  • Try to place this dll next to your blender.exe (software OGL, will be slow, but will show whether this is a driver issue or not).

No problem:

  • OS and drivers up to date
  • GPU driver supports openGL 1.4
  • No change when running factory settings
  • I tried to tweak some settings in user>preferences> system without success
  • System infos:
  • I placed opengl32.dll in blender directory... No change except Blender is slower and interface very slow

Don't hesitate to ask me to test some .diff if you have any idea of what can cause the bug and thank you very much for trying to solve it!

Thanks. If you are building Blender yourself (and hence have a local git repo of its source), you may want to try to revert those two commits, and see whether it fixes the issue:


Those were switching from plain C malloc/realloc/free to our own guarded versions (used nearly everywhere in Blender code, MEM_xxx). I would not expect for sure this to be the cause of the issue, but you never know…

Otherwise, you could also just git bisect between the known good and bad revisions, to pinpoint which change actually caused the issue.

I already made bisect:

This is since this commit:

the bug appeared...

I just wanted to report the bug... But my own build 2.73.6 works fine! :) Thanks. I'll try to revert the commits you indicated to me to see what happens.

Oh… then I know what’s the issue - you must have some invalid (as in, not reachable) bookmarks. Would look like running BLI_is_dir from draw loop is not a good idea. :/
Will try to think of a better solution.

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.Feb 16 2015, 3:04 PM

That commit should fix the issue, can you please confirm this?

Sorry, that does not work for me.

Compilation warnings:

When I revert your commit b9ffd70960c5047a003fadf2363bfed50095d79b it works.

I make a new try... But I think it won't change.

Will confirm once buildbot updates

After another test, I realized that your last changes solved a part of the bug:

  • When you click on the open button, there is the same lag to reach the selection file menu.
  • But when you are in the selection file menu, there are no more lag.

Hope this can help!

@Bastien Montagne (mont29) , we have updated based off the buildbot (691cb61) and performance has significantly improved whilst navigating between folders & files... The only slowdown now occurs when the file dialogue is opening... (Pressing Ctrl - O will lock up blender for 5-10 seconds)

I have tried resetting the preferences and that does not help with the lockup. Nor does removing mounted network drives / removing network drive shortcuts

I can confirm that this slowdown happens for all File Browser dialogues (open / save as / link / append / changing the 3dview to filebrowser manually).

Yes… that what I would have expected… I’d like to know how much entries you have in your bookmarks, and if many of them are pointing to network FS (I bet there are :P).

No, issue here comes from calling BLI_is_dir() on all bookmarks' paths, to detect the one which are available and the one which are currently invalid. Previously, it was run on each redraw, which was stupid from my side. Now, I made them run only on blender startup and when you open a file browser. I could just keep it to run only once on startup, but then it would not update if you e.g. mount a new drive or whatever… :/

I tried removing all blender bookmarks actually... even wiped my settings and tried it again, still lagged out. Tried unmounting my network drives and removing network bookmarks from the filebrowser, and that lagged out still.

Note Campbell did another (unrelated) fix regarding filebrowser and lag, rB8cb4011220bffae55, is it in your tested builds?

I was using build 691cb61 from the buildbot, so yes?

I just updated my Blender sources and made a new build. Same issue. In my system bookmarks, I've only Desktop and Documents. I don't know what exactly is a "bookmark"... In the help menu, there are several internet links "bookmarks" (python API reference etc...). Thank you mont29 for trying to resolve the bug!

I have a drive A: in bookmarks which does not exists (my hard drives are C: , D: , and cdroms E: , F: ) . When I click on A: , Blender crashes sometimes. I don't know if it is related to the bug...

Grmll… trying to fix that without being able to reproduce it is rather hairy… Can you please apply that patch, run Blender, open once or two times the filebrowser, and paste here what it prints in console?

1diff --git a/source/blender/editors/space_file/fsmenu.c b/source/blender/editors/space_file/fsmenu.c
2index f717573..d1a0ce6 100644
3--- a/source/blender/editors/space_file/fsmenu.c
4+++ b/source/blender/editors/space_file/fsmenu.c
5@@ -216,14 +216,21 @@ void ED_fsmenu_entry_set_name(struct FSMenuEntry *fsentry, const char *name)
6 }
7 }
9+#include "PIL_time_utildefines.h"
10 void fsmenu_entry_refresh_valid(struct FSMenuEntry *fsentry)
11 {
12+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
13+ TIMEIT_START(validate_entry);
15 if (fsentry->path && fsentry->path[0]) {
16 fsentry->valid = BLI_is_dir(fsentry->path);
17 }
18 else {
19 fsentry->valid = false;
20 }
22+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
23+ TIMEIT_END(validate_entry);
24 }
26 short fsmenu_can_save(struct FSMenu *fsmenu, FSMenuCategory category, int idx)
27@@ -656,12 +663,18 @@ void fsmenu_refresh_bookmarks_status(struct FSMenu *fsmenu)
29 int i;
31+ printf("%s: ", __func__);
32+ TIMEIT_START(validate_fsmenu);
34 for (i = sizeof(categories) / sizeof(*categories); i--; ) {
35 FSMenuEntry *fsm_iter = ED_fsmenu_get_category(fsmenu, categories[i]);
36 for ( ; fsm_iter; fsm_iter = fsm_iter->next) {
37 fsmenu_entry_refresh_valid(fsm_iter);
38 }
39 }
41+ printf("%s: ", __func__);
42+ TIMEIT_END(validate_fsmenu);
43 }
45 void fsmenu_free(void)

It seems there is a problem with A:, no?

validate A:\: time start (validate_entry): D:\Compilation\Blender\No
uveau dossier\source\blender\editors\space_file\fsmenu.c:223

validate A:\:    time end   (validate_entry): 5.546460

That’s the least we can say… Windows! A:\ and B:\ are for (very!) old floppy stuff, think I will just explicitly exclude them from the check for now… But win could be smart enough not to block five seconds for a mere stat call over such stuff…

Can you confirm me this patch fixes the issue for you?

1diff --git a/source/blender/editors/space_file/fsmenu.c b/source/blender/editors/space_file/fsmenu.c
2index f717573..12ba9db 100644
3--- a/source/blender/editors/space_file/fsmenu.c
4+++ b/source/blender/editors/space_file/fsmenu.c
5@@ -216,14 +216,35 @@ void ED_fsmenu_entry_set_name(struct FSMenuEntry *fsentry, const char *name)
6 }
7 }
9+#include "PIL_time_utildefines.h"
10 void fsmenu_entry_refresh_valid(struct FSMenuEntry *fsentry)
11 {
12+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
13+ TIMEIT_START(validate_entry);
15 if (fsentry->path && fsentry->path[0]) {
16+ /* XXX Special case, always consider those as valid.
17+ * Thanks to Windows, which can spend five seconds to perform a mere stat() call on those paths...
18+ * See T43684.
19+ */
20+ const char *exceptions[] = {"A:\\", "B:\\", NULL};
21+ const size_t exceptions_len[] = {strlen(exceptions[0]), strlen(exceptions[1]), 0};
22+ int i;
24+ for (i = 0; exceptions[i]; i++) {
25+ if (STREQLEN(fsentry->path, exceptions[i], exceptions_len[i])) {
26+ fsentry->valid = true;
27+ return;
28+ }
29+ }
30 fsentry->valid = BLI_is_dir(fsentry->path);
31 }
32 else {
33 fsentry->valid = false;
34 }
36+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
37+ TIMEIT_END(validate_entry);
38 }
40 short fsmenu_can_save(struct FSMenu *fsmenu, FSMenuCategory category, int idx)
41@@ -656,12 +677,18 @@ void fsmenu_refresh_bookmarks_status(struct FSMenu *fsmenu)
43 int i;
45+ printf("%s: ", __func__);
46+ TIMEIT_START(validate_fsmenu);
48 for (i = sizeof(categories) / sizeof(*categories); i--; ) {
49 FSMenuEntry *fsm_iter = ED_fsmenu_get_category(fsmenu, categories[i]);
50 for ( ; fsm_iter; fsm_iter = fsm_iter->next) {
51 fsmenu_entry_refresh_valid(fsm_iter);
52 }
53 }
55+ printf("%s: ", __func__);
56+ TIMEIT_END(validate_fsmenu);
57 }
59 void fsmenu_free(void)

Yes! It works again! Thanks very much! And thank you for all your works for Blender!
Bonne fin d'après-midi!

Cool, committing then, then again for the tests!

(Et bonne soirée :) ).

Oops! Sorry it's me again. I just tested you commit. Compilation failed. I propose this patch:

foreach ($list as $item) {

diff --git a/source/blender/editors/space_file/fsmenu.c b/source/blender/editors/space_file/fsmenu.c
index 6b4ee31..242464c 100644
--- a/source/blender/editors/space_file/fsmenu.c
+++ b/source/blender/editors/space_file/fsmenu.c
@@ -229,7 +229,7 @@ void fsmenu_entry_refresh_valid(struct FSMenuEntry *fsentry)
 		int i;
 		for (i = 0; exceptions[i]; i++) {
-			if (STRCASEEQLEN(fsentry->path, exceptions[i], exceptions_len[i])) {
+			if (STREQLEN(fsentry->path, exceptions[i], exceptions_len[i])) {
 				fsentry->valid = true;


Pardon pour la mise en page :)

@Ulysse Martin (youle), do you mean compilation of latest master fails or something regarding Bastien's patch?

Yes compilation failed because of line 232 in \blender\source\blender\editors\space_file\fsmenu.c if (STRCASEEQLEN(fsentry->path, exceptions[i], exceptions_len[i])) {

This line has to be replaced by:

if (STREQLEN(fsentry->path, exceptions[i], exceptions_len[i])) {

to make it work. That was the mont29 first intention (cf his patch above)... But I don't know why he changed it. :)

Yes, compilation of the last updated master with his commit included...