Lag in "File View" #69530

New Issue

Marcin Twarowski · 2019-09-05T11:16:26+02:00

Marcin Twarowski commented

2019-09-05 11:16:26 +02:00

System Information
Operating system: Windows-10-10.0.16299 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.15

Blender Version
Broken: version: 2.81 (sub 8), branch: master, commit date: 2019-09-05 02:56, hash: 6fc6f2504d

Short description of error
"File View" window noticeably lags when moved around. After some time it stops lagging and becomes smooth.

Exact steps for others to reproduce the error

Start new session of Blender
"File" > "Open" (or "ctrl+o")
Move the "Blender File View" around rather quickly.

Lagging is quite noticeable, as if something was loading to memory, but after some time it stops and becomes buttery smooth.

Edit: Tested on a weaker machine:
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.15

The performance drop is more noticeable and doesn't seem to get better over time.
Also, if you move main window around, while file menu is open you'll notice the same issue. If you minimize the file menu and then move main window around, it performs smooth.

**System Information** Operating system: Windows-10-10.0.16299 64 Bits Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.15 **Blender Version** Broken: version: 2.81 (sub 8), branch: master, commit date: 2019-09-05 02:56, hash: `6fc6f2504d` **Short description of error** "File View" window noticeably lags when moved around. After some time it stops lagging and becomes smooth. **Exact steps for others to reproduce the error** - Start new session of Blender - "File" > "Open" (or "ctrl+o") - Move the "Blender File View" around rather quickly. Lagging is quite noticeable, as if something was loading to memory, but after some time it stops and becomes buttery smooth. **Edit:** Tested on a weaker machine: Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.15 The performance drop is more noticeable and doesn't seem to get better over time. Also, if you move main window around, while file menu is open you'll notice the same issue. If you minimize the file menu and then move main window around, it performs smooth.

Marcin Twarowski commented

2019-09-05 11:16:26 +02:00

Added subscriber: @MarcinTwarowski

blender-admin commented

2019-09-05 11:16:26 +02:00

#71933 was marked as duplicate of this issue

Germano Cavalcante commented

2019-10-16 20:10:53 +02:00

Added subscribers: @mont29, @mano-wii

Germano Cavalcante commented

2019-10-16 20:10:53 +02:00

I can't reproduce the problem.

System Information
Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13559 Core Profile Context 26.20.12028.2

@mont29, do you have any idea what could be wrong?

I can't reproduce the problem. **System Information** Operating system: Windows-10-10.0.18941 64 Bits Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13559 Core Profile Context 26.20.12028.2 @mont29, do you have any idea what could be wrong?

Marcin Twarowski commented

2019-10-16 20:55:35 +02:00

To clarify, it's not a dramatic loss of performance, but it's noticeable in my opinion. Here's a video:
Blender_file_view.mp4
I noticed that animation underneath stops when you click on a file view window. I found it interesting.

To clarify, it's not a dramatic loss of performance, but it's noticeable in my opinion. Here's a video: [Blender_file_view.mp4](https://archive.blender.org/developer/F7826471/Blender_file_view.mp4) I noticed that animation underneath stops when you click on a file view window. I found it interesting.

Harley Acheson commented

2019-10-16 21:13:04 +02:00

Added subscriber: @Harley

Harley Acheson commented

2019-10-16 21:13:04 +02:00

Is this behavior the same if the window that is in front is Preferences, rather than File Browser? I think this is more to do with redrawing of the main window behind than with the window in front.

Is this behavior the same if the window that is in front is **Preferences**, rather than File Browser? I *think* this is more to do with redrawing of the main window behind than with the window in front.

Clément Foucault commented

2019-10-16 21:24:07 +02:00

Added subscriber: @fclem

Clément Foucault commented

2019-10-16 21:24:07 +02:00

If that's happening using the Preference Window, that could be because of the OpenGL context switching between windows. That said, we did not change much in this regard compared to 2.79.

Marcin Twarowski commented

2019-10-16 21:25:42 +02:00

In case of 'preferences' I see a drop to 48 FPS, rather than 25 like with File window. So the impact seems to be there, although noticeably smaller. This is on a GTX 750 Ti by the way.
I just checked 2.79 and moving preferences window around is really bad. I never noticed that before. 2.81 is a lot smoother.

In case of 'preferences' I see a drop to 48 FPS, rather than 25 like with File window. So the impact seems to be there, although noticeably smaller. This is on a GTX 750 Ti by the way. I just checked 2.79 and moving preferences window around is really bad. I never noticed that before. 2.81 is a lot smoother.

Harley Acheson commented

2019-10-16 22:23:11 +02:00

Hmmm... you are right, the slowdown is greater with File Browser.

However, (at least for me) the slowdown is almost nothing if I don't allow fsmenu_read_system() do any work - the reading of volumes and system folders. Not sure if we need to reload those on every draw.

Hmmm... you are right, the slowdown is greater with File Browser. However, (at least for me) the slowdown is almost nothing if I don't allow fsmenu_read_system() do any work - the reading of volumes and system folders. Not sure if we need to reload those on every draw.

Harley Acheson commented

2019-10-17 00:24:42 +02:00

Taking a closer look it gets a bit stranger...

space_file.c file_init() is called four times in succession each and every time the File Manager is opened. And is called periodically while the window is dragged around.

Almost all the slowdown I experience is when that function calls fsmenu_refresh_system_category(). So that function is clearing the volumes and system lists and recreating them, four times when the window opens and periodically while dragging around.

If that function is not called in file_init(), not only is the slowdown gone but everything still seems to work just fine and those lists are populated properly. In fact, I can just make "file_init" do nothing at all by adding a "return;" and everything works just fine. But faster.

Taking a closer look it gets a bit stranger... space_file.c file_init() is called four times in succession each and every time the File Manager is opened. And is called periodically while the window is dragged around. Almost all the slowdown I experience is when that function calls fsmenu_refresh_system_category(). So that function is clearing the volumes and system lists and recreating them, four times when the window opens and periodically while dragging around. If that function is not called in file_init(), not only is the slowdown gone but everything still seems to work just fine and those lists are populated properly. In fact, I can just make "file_init" do nothing at all by adding a "return;" and everything works just fine. But faster.

Julian Eisel commented

2019-10-17 11:56:39 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2019-10-17 11:56:39 +02:00

Hmm, don't see why there would be a need to call it that often. We should be able to early-exit in most cases and only refresh on directory change or if the user pressed the refresh button or so.

But this is really more @mont29's area :)

Hmm, don't see why there would be a need to call it that often. We should be able to early-exit in most cases and only refresh on directory change or if the user pressed the refresh button or so. But this is really more @mont29's area :)

Harley Acheson commented

2019-10-21 18:40:25 +02:00

In the end this seems to come down to the fact that SpaceType.init() is misnamed. It is called all over, multiple times in a row, and all the time constantly while doing some things. So it cannot be used for one-time initialization stuff that you might expect to put in something called init.

Looking at Outliner, for example, that st->init is completely empty.

So the solution is to just find better places to put the only two two things it is doing: fsmenu_refresh_system_category(), which is recreating the entries in Volumes and System, and fsmenu_refresh_bookmarks_status(), which stops and restarts a job that validates the user bookmarks. Neither is something we want called four times in a row and then constantly while dragging.

In the end this seems to come down to the fact that SpaceType.init() is misnamed. It is called all over, multiple times in a row, and all the time constantly while doing some things. So it cannot be used for one-time initialization stuff that you might expect to put in something called init. Looking at Outliner, for example, that st->init is completely empty. So the solution is to just find better places to put the only two two things it is doing: fsmenu_refresh_system_category(), which is recreating the entries in Volumes and System, and fsmenu_refresh_bookmarks_status(), which stops and restarts a job that validates the user bookmarks. Neither is something we want called four times in a row and then constantly while dragging.

Harley Acheson commented

2019-10-27 22:41:11 +01:00

A possible fix here:

https://developer.blender.org/D6112

A possible fix here: https://developer.blender.org/D6112

Julian Eisel commented

2019-11-26 17:08:36 +01:00

Added subscriber: @MrBeep

blender-admin commented

2019-11-27 00:53:07 +01:00

This issue was referenced by 7af5604389

This issue was referenced by 7af560438966c5b3f7a0203fefd8bbad80d201c9

Harley Acheson commented

2019-11-27 00:54:44 +01:00

Changed status from 'Open' to: 'Resolved'

Harley Acheson closed this issue

2019-11-27 00:54:44 +01:00

Harley Acheson self-assigned this 2019-11-27 00:54:44 +01:00

Arbaz Arif commented

2020-01-01 22:29:41 +01:00

Added subscriber: @AcidRain0

Arbaz Arif commented

2020-01-01 22:29:41 +01:00

In #69530#797133, @fclem wrote:
If that's happening using the Preference Window, that could be because of the OpenGL context switching between windows. That said, we did not change much in this regard compared to 2.79.

Yes in my case preferences is even slower than file view when moving around or resizing

Any seperate window Like File browser, Preferences, Render View etc is affected by the same issue to varying degrees

> In #69530#797133, @fclem wrote: > If that's happening using the Preference Window, that could be because of the OpenGL context switching between windows. That said, we did not change much in this regard compared to 2.79. Yes in my case preferences is even slower than file view when moving around or resizing Any seperate window Like File browser, Preferences, Render View etc is affected by the same issue to varying degrees

Manuel Hofmann commented

2022-05-20 20:45:22 +02:00

Added subscriber: @ManuH

Manuel Hofmann commented

2022-05-20 20:45:22 +02:00

i can confirm the same and i have very powerful hardware (latest intel XE + RTX 6000 gpu)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Lag in "File View" #69530