File Browser is unusable on Windows Machines
Closed, ResolvedPublic
Actions

Description

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

Go onto a windows computer
try saving as
wait 10-15 seconds for it to load the current directory
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.

Revisions and Commits

rB Blender
	rBe089b0e91162 Amend to previous own Fix T43684: only use hack on WIN32, and use case…
	rB21a2b73a1e0e Fix T43684 (again!): Mighty Windows thinks it’s perfectly sensible to block…
	rB0dfdca6d132d Fix T43684: File Browser is unusable on Windows Machines (do not BLI_is_dir()…

Related Objects

Mentioned Here: rB2967253ae4f0: Fix Windows build.
P202 T43684
P201 T43684
rB8cb4011220bf: Revert "Fix file size not drawn using Link/Append"
rB691cb61835dc: Fix for another missing update from GPencil in Outliner
rBb9ffd70960c5: FileBrowser Bookmarks: fix issue with invalid bookmarks.

Event Timeline

Carlo Andreacchio (candreacchio) created this task.Feb 16 2015, 7:05 AM

Carlo Andreacchio (candreacchio) raised the priority of this task from to 90.

Carlo Andreacchio (candreacchio) updated the task description. (Show Details)

Carlo Andreacchio (candreacchio) added a project: BF Blender.

Carlo Andreacchio (candreacchio) edited a custom field.

Carlo Andreacchio (candreacchio) added a subscriber: Carlo Andreacchio (candreacchio).

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). ;)

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: http://www.mediafire.com/view/g7ccuwo38ovt7qf/system-info.txt
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:

2e9105cc964a157458663fa8102601e3d6ac90e3
f1ee11fcca20ce1fb7db97a71e7e345c6faad69a

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: http://www.mediafire.com/view/w8thde9z7drbmif/bisectLagBlender.txt

This is since this commit: https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/b9ffd70960c5047a003fadf2363bfed50095d79b

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 30 to Normal.Feb 16 2015, 3:04 PM

Closed by commit rB0dfdca6d132d.

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

Sorry, that does not work for me.

Compilation warnings: http://www.mediafire.com/view/f6mwlefcqdfzbyn/warnings.txt

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?

P201 T43684

1	diff --git a/source/blender/editors/space_file/fsmenu.c b/source/blender/editors/space_file/fsmenu.c
2	index 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	}
8
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);
14	+
15	if (fsentry->path && fsentry->path[0]) {
16	fsentry->valid = BLI_is_dir(fsentry->path);
17	}
18	else {
19	fsentry->valid = false;
20	}
21	+
22	+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
23	+ TIMEIT_END(validate_entry);
24	}
25
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)
28	int categories[] = {FS_CATEGORY_SYSTEM, FS_CATEGORY_SYSTEM_BOOKMARKS, FS_CATEGORY_BOOKMARKS, FS_CATEGORY_RECENT};
29	int i;
30
31	+ printf("%s: ", __func__);
32	+ TIMEIT_START(validate_fsmenu);
33	+
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	}
40	+
41	+ printf("%s: ", __func__);
42	+ TIMEIT_END(validate_fsmenu);
43	}
44
45	void fsmenu_free(void)

Hello! No problem: http://www.mediafire.com/view/8ly6c56s3l0os9p/Nouveau_document_texte.txt

Hope this helps! Bon courage!

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… F...ing 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?

P202 T43684

1	diff --git a/source/blender/editors/space_file/fsmenu.c b/source/blender/editors/space_file/fsmenu.c
2	index 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	}
8
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);
14	+
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;
23	+
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	}
35	+
36	+ printf("\tvalidate %s: ", (fsentry->path && fsentry->path[0]) ? fsentry->path : "<empty bookmarks>");
37	+ TIMEIT_END(validate_entry);
38	}
39
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)
42	int categories[] = {FS_CATEGORY_SYSTEM, FS_CATEGORY_SYSTEM_BOOKMARKS, FS_CATEGORY_BOOKMARKS, FS_CATEGORY_RECENT};
43	int i;
44
45	+ printf("%s: ", __func__);
46	+ TIMEIT_START(validate_fsmenu);
47	+
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	}
54	+
55	+ printf("%s: ", __func__);
56	+ TIMEIT_END(validate_fsmenu);
57	}
58
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 :) ).

Closed by commit rB21a2b73a1e0e.

Bastien Montagne (mont29) added a commit: rBe089b0e91162: Amend to previous own Fix T43684: only use hack on WIN32, and use case….Feb 17 2015, 9:11 PM

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;
 				return;
 			}

  ($item);
}

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...

That's because of this commit: https://git.blender.org/gitweb/gitweb.cgi/blender.git/blobdiff/5115e862460203c5e31bb5d62acc3fda2b0cc2bd..e089b0e91162fb0932bdb88e9905cdd9fb6b94dd:/source/blender/editors/space_file/fsmenu.c

Fixed as rB2967253ae4f080 (stupid MSVC again).

File Browser is unusable on Windows MachinesClosed, ResolvedPublicActions

Description

Revisions and Commits

Related Objects

Event Timeline

File Browser is unusable on Windows Machines
Closed, ResolvedPublic
Actions