Slow saved layout change

What is in the layouts? Are we talking hundreds of windows and tabs?

Do any of the tabs point to network drives which are not reachable? Those can cause a 30 second timeout in some situations. (We try to avoid it and keep it on background threads, but it's not always possible, nor easy to predict when it will/won't happen.)

5 tabs single pane, 6 with dual both with a always on network drive. Works most of the time hangs maybe %30 of the time

One thing I'm just noticing when there is a .jpg in the viewer pane is when it takes a while

The viewer pane should be blank immediately after loading a layout, unless you have a script doing something.

Yes but if I click a .jpg then it is not blank, that's the purpose of it, then when I switch to a different layout is when it hangs.

Are we really talking about Layouts or Styles?

Layouts usually open new windows and either leave or close existing windows. Styles usually changes one existing window.

Layouts...one is a single display with a tree and a viewer pane and 2 is a dual display with a tree and viewer pane spanning 2 monitors

What's the relationship between the old window that has an image shown in the viewer, and the new window that opens as part of the layout?

Is the old window still open after you do that, or is it being closed?

(Or is it being turned into the new "layout" without closing? If so, which command are you using to do that, as it doesn't normally happen with layouts via any of the built-in menus, only with styles.)

dave@dmtl.net


This is getting a little tiresome. When I switch between the 2 layouts shown with a jpg in the viewer pane it hangs. That's as simple as I can make it.

What are you clicking to switch between them?

Settings/Lister Layouts/ then choosing one of my saved layouts

Thanks. It's very odd if having a jpeg loaded into the viewer is a factor when using that menu, since the old window would just be closed completely before the new one is opened (assuming the layout is configured to close old windows).

Would it be possible to generate some manually created dumps while the delay is happening? We should be able to look at those and see where in the code the delay is happening.

Here is a link [link removed]. I'm on satellite so it would not upload here. It's not real critical. If I remember to put something other than an image in the viewer pane it won't hang.

Thanks for the dumps! Unfortunately, it looks like nothing much was happening in the process at the time they were taken. All of our threads were idle and waiting for user input. (There are some other threads created by Windows, but most of those look the same, and none stand out as meaningful.)


If you want to, a Process Monitor log might reveal a filesystem operation that is taking a long time: Process Monitor instructions


Looking at the screenshots, the layout is opening into a folder which has a large archive and a large installer/exe in it. Those could trigger lengthy virus scans when Opus inspects the files or asks for their icons, which can freeze the process (depending on how the antivirus scanner works). I wonder if you would see the same issue if the layout pointed to different/empty folders, or if any archives/exe files were moved out of the starting folders.

That wouldn't explain why it only seems to happen if the viewer is showing a JPG, though. That aspect is a mystery to me as it should not affect anything.

Thanks for everything but as I said It's not real critical. I'll just live with it. If I remember to put something other than an image in the viewer pane before switching layouts it won't hang. I just thought if it was something simple I would like it fixed.

I looked at this again this evening and was able to reproduce the problem.

A fix will be in the next beta.

Thanks for sticking with it. The info above helped track down what was happening.

Thanks a lot. Looking forward to the fix.

Here's the fix. Let us know if you still see any problems:

That fixed it. Thanks

1 Like