Resizing Opus 12's window is laggy

Help & Support
1

In another topic, I previously mentioned that Opus doesn't perform as well as it probably should when it comes to resizing its window. I don't believe my CPU would be a limiting factor having 8 cores / 16 threads. With my desired configuration, my Opus updates at a rate of about 4 FPS during resize.

Some anecdotal things I've noticed that improve the update rate:

  • Using a single display mode increases the update rate by ~double. Using a dual display mode can help exaggerate and thus help identify certain parts of the UI adding lag, which is the mode that my Opus is set to for the rest of these observations.
  • Entering Customize mode will render some UI elements as basic outlines, reducing resize lag.
  • With a dual display mode in effect and a Path Field in the Border set to Field Type > Path (Breadcrumbs), once the UI element can't be seen any longer (e.g. decreasing the window width at a constant speed), the update rate increases by ~double. For example, you can add two UI Spacers to help offset the Path Field to the right to make it easier to test.
  • Field Type > Path (Breadcrumbs) has a worse update rate than when set to Path (Basic).
  • Setting the Border preference Display as a static header drastically improves update rate.

This all points to the Border being a fairly significant source of the problem, and too the duplication of UI/logic needed when using two file displays. Perhaps some optimisations are possible here? I haven't noticed anything else contributing to the issue, but I'll attempt to keep this topic updated with any new findings.

Please let me know if there's anything I could provide to help improve the situation.

Thanks!

- Directory Opus v12.23.2 Beta x64 Build 7734
- Windows 10 v20H2 OS Build 19042.868
2

I just upgraded from 11 and notice the same thing. Resize seems laggy.

1 Like
3

Here's a recording of Opus' resize performance in comparison to another program (other more complex programs such as Firefox also perform well whilst resizing). Despite the performance being fairly poor, it's better than what I'm used to with my customised configuration by a factor of ~2 (the video is recorded with Opus' config reset to default).

It shouldn't be this bad out-of-the-box, so-to-speak, which leads me to think something on my system is conflicting somehow. What? I don't know. Some programs that also display lists (like Foobar2000 and Mp3tag) also resize poorly. From what I've seen in some videos, Opus should perform better than this on resize. Maybe the videos featured earlier versions of the software?

Thanks.

4

Interesting... never noticed this problem until now, because Show window contents while dragging had been disabled on my systems for the past 20 years :smiley:

True, resizing an Opus lister is not as smooth as e.g. VS Code, but to me it seems choppy rather than laggy. A design decision rather than a performance problem.

I'll report back once I get my 48 core thread ripper monster :wink:

1 Like
5

It seems, autosize-columns slows down resize. But here on my Surface 7 and PC with 4k/i7/2070S delay is very minimal on resize.

On default konfig with no-autofill I notice no delay.

6

Choppy may have been a better choice of word. I'm interested in how you see this choppiness as a design choice rather than poor performance. What would the slow update rate be solving?

I set my User Default Folder Format so that all its field are set to Expand (meaning no auto-sizing of columns) and made sure my File Displays were using the updated format, yet I didn't notice any improvement unfortunately.

My system's CPU has 16 threads and I don't think the dedicated GPU should be a limiting factor either.

7

We made a couple of small changes in the new beta which seem to have helped (on Windows 10). Give it a try and let us know how you find it.

8

Yes, they have.

Doesn't affect me much, but still a nice improvement.

image
image419×602 13 KB

:smiley:

9

I just tried turning off all those Performance Options other than Show window contents while dragging to see if it'd he, but no. I think the option to not show the contents of the window is only masking that a problem is there, at least, on my machine.

Is it possible to downgrade to the previous beta?

The update didn't change anything for me when it comes to resizing, but I'd like to confirm that something else I'm noticing wasn't introduced in Beta 4: when the window clips outside of the screen's bounds, it becomes choppy whilst moving until it returns to completely inside the bounds again.

Edit: I tried booting into Safe Mode and the program did perform noticeably better, though some choppiness did remain (I'd say an acceptable amount, but ideally there's be none like in other software on the system). Back in normal boot mode I ended most user processes and non-Microsoft services, and there was only a slight improvement. Since I can't seem to eliminate the choppiness completely, it gives me the impression that the cause is in Opus and not something on my system.

11

If it's smoother in safe mode than normal, there may be something wrong with your GPU drivers, since it'd normally be the other way around (since Safe Mode is more likely to fall back on a generic, slow-but-safe GPU driver, and the real driver should always be faster if it's working correctly).

That or one of the Windows options (maybe even one you've been changing recently?) has made things worse rather than better, and gets ignored by Safe Mode.

12

My GPU drivers are from February and were installed after used Opus for the first time. The choppiness has been like this since then as far as I can recall. I haven't noticed poor performance in games (or software such as Photoshop), and a clean install of the latest Nvidia drivers which I just performed didn't help either.

I may have changed a Windows option before installing Opus, but what could affect it in this manner, I'm not sure.

I've always presumed programs like Foobar2000 and Mp3tag (which are both choppy on resize for me) are due to how much text they display (due to columns/lists). For example in Mp3tag (which is worse than Opus), if I hide something called the Tag Panel which has around 40 text fields, and reduce either the number of columns, or the amount of listed files, resizing returns back to being snappy. Similarly in Opus, the more I reduce the number of UI elements on display, I notice the responsiveness increase bit by bit, but not to the point of what I'd call ideal.

Another observation in Mp3tag: if I drag-select more than 3-4 listed files, the blue selection rectangle which follows the cursor starts to slow to similar rate of the choppiness when window resizing.

A third general observation: all three of the mentioned programs have this slowdown I mentioned in my previous post (potentially indicating a related issue) about when the window in a restored state goes outside of the screen's bounds, whereas other programs like Firefox, Discord, and File Explorer, are not affected.

What adds doubt to it being a column/list rendering issue is that another program, a torrent client, which also displays long lists and many columns, doesn't seem to suffer from a choppy window or a performance drop due to number of listed items. But maybe its implementation differs to the others?

Opus' perceived slowness isn't only limited to the speed of its window resizing, but also things like the smoothness of its animations navigating from one folder to the next.

I can only report what I observe, and I'm not sure what else I could test that could prove useful in understanding what's going on.

13

Foobar is very smooth for me, and the transition animations in Opus are hardware accelerated. It sounds like there's an issue specific to your PC which is affecting lots of software.

1 Like
14

One counterintuitive issue I ran into with my current PC is it was frequently stuttering while doing basic desktop stuff. It turned out to be the CPU going into low power states because it didn't have enough to do (and the motherboard drivers/BIOS were garbage at the time). Disabling most of the C-states in the BIOS fixed that. I wouldn't be surprised if they're disabled in Safe Mode automatically. Maybe you're seeing something similar.

(GPUs can run into the same issue, but usually only in light games, at least in my experience.)

15

It's possible there's something wrong with my PC, but I wouldn't say the issue is affecting a lot of software, at least, not noticeably. However, it does appear to be broader than just Opus, so I'll have to see what I can do. I'll look into the BIOS and the possibility of low power states. Sounds like a good idea, thanks.

Here's a screenshot from HWiNFO in the meantime:

CPU

Interestingly, the chipset has the words "Low-Power" and I don't know why, or if it's even relevant. The CPU minimum looks low too. When I'm resizing, the CPU stays at 4 GHz+, so you'd think it would have enough juice. My Windows Power Options also have Minimum processor state set to 100%. Maybe the BIOS settings are overriding this, as the CPU clock does fluctuate between ~3-4 GHz.

Edit: And Ryzen Master:

CPU-Ryzen-Master
CPU-Ryzen-Master1190×978 160 KB

16

If you have Ryzen, only Ryzen Master shows CPU state reliably.

1 Like
17

Have you tried to set Ryzen Balanced power plan? There's virtually no use to run CPU at 100% all the time.
Said that, my Opus behaves similar to yours - maybe a bit better, but difference to fe. Notepad++ is visible. Opus has much more windows contents to handle though.

18

It's nearly without delay now here.

I wonder that some people here turn of performance options. The should not make that remarkable differences on actual devices.