Hi, I was doing some google searches a month or 2 ago to figure out why my dopus was suddenly performing very slowly. I found some forum responses that apparently led nowhere and I gave up my search then.
Until it dawned on me, that perhaps the laggy scrolling was due to some opacity related stuff. My first thought was, grid lines. I went into the options, and sure enough, disabling grid lines completely improved scroll performance 10,000% (exaggeration of course, but the lag completely disappeared).
I then decided to re-enable grid lines and set the opacity to 100% for both. This worsened scroll performance significantly, which is strange because 100% opacity shouldn't be creating such a strain on my PC.
One thing is for sure, disabling grid lines definitely made the most significant improvement. The laggy scroll performance practically disappears.
Setting an opacity value to anything less than 100% results in severely laggy scroll performance.
Setting an opacity value to 100% results in moderate laggy scroll performance.
Suggested workaround - If a user chooses a 100% opacity value, then switch to a less performance intensive calculation to achieve better scroll performance.
Even better suggestion: Eliminate all performance problems by reprogramming this entirely, as it seems to be poorly implemented based on my very non-thorough deduction.
Are you using a background image or anything like that? Or any columns with background colors, or similar that might impact things?
Are you seeing this with 12.9, or an earlier version?
Do you have graphics drivers installed from the GPU manufacturer (NVidia, AMD, etc.)? The drivers that come built into Windows are extremely slow at some operations (in my experience with NVidia cards). Also note that Windows 10 tends to downgrade you to built-in drivers when it does its major updates every 6 months.
"Also note that Windows 10 tends to downgrade you to built-in drivers when it does its major updates every 6 months"
It also insists on installing the ASUS smart mouse which sucks over my synaptics which is always a pain to re-install which is why my connection is set toe metered and I have chosen not to install the 1803 upgrade so far.
Many thanks for the excellent video! That helps understand what you're seeing and what to look for.
I'm finding that if I add a lot of extra columns to a full-screen (4K) window, and turn on both horizontal and vertical grid-lines, I see a slight decrease in scrolling speed, but nothing like as much as what you're seeing there. What I'm seeing with my config is along the lines of "doing more takes longer", but what you're showing in the video is beyond that into "something is making things ridiculously slow for no good reason".
I wonder if the problem is from some other settings that may not be obvious. e.g. I have relative size graphs displayed as separate columns instead of under the main size column, which I haven't tried yet. There could be lots of things like that, and it might be several things adding up instead of a single setting.
To save time, would it be possible for you to send us a backup of your config, so we can try with exactly the same thing?
If you're OK with doing that, you can make a config backup using Settings > Backup & Restore. The .ocb file it outputs is really a Zip archive if you rename the extension, and most of the config data is text/xml, if you want to look inside to see if there's anything you want to keep private. (e.g. Stored FTP passwords is the main one, and of course not something that will matter to reproducing the problem.) Please also send it via private message (or email to leo@gpsoft.com.au if preferred).
Do you have smooth scrolling enabled in "Prefs / File Displays / Mouse"? (From your video, it seems to be the case.)
It might be unrelated to your problem, but in my experience it's a performance killer, especially when many files are selected and opacity is activated (on top of coloured columns).
This issue came up again today ( Laggy scrolling in Lister ) and I think we've got to the bottom of it now. It's probably what you were seeing as well.
We've made some code changes for the next beta (12.16.3) which fix the underlying problem.
In the meantime, if you turn off Preferences / File Display Modes / Details / Vertical for now, you should see a big improvement, but once the new version is out you should be able to turn it on without the big performance hit.
I'm experiencing a similar problem when I turn Horizontal grid lines on. I'm using 20% opacity. I do not have vertical grid lines on, my videocard drivers and DOpus installation are up to date, and I have a Ryzen 7 2700X along with a Radeon RX 570 series card.
Back when this computer only had a Ryzen 3 2200G processor, I had this issue too. Things were running fine. I was scrolling with full speed with all the fancy grid lines I wanted with no issue, then it rapidly started to degrade and get slower and more stuttery. Then I turned the grid lines off and got a big scrolling boost for a long while. I just decided to turn the grid lines on again today to check it out, and I'm noticing a lag in scrolling speed.
When lines are on, I'm not actively scrolling, and I'm in a folder with predominately images, there's usually less than 1% CPU usage. Maybe 1.3% if DOpus is doing something in the background for an instant like displaying a dropdown menu. The inactive usage with lines off is basically the same.
When lines are on and I'm actively scrolling up and down in detail mode in a directory with about 124 images in it and I get the noticeable lag, CPU usage from DOpus spikes to 6 or 7%. Going into a directory with 1,200+ images in it in details mode (thumbnails not displayed) and scrolling rapidly up and down can make the CPU usage spike to almost 10%. Tested with the video folder described below, got similar numbers.
With lines off, scrolling fast in the 1,200+ image folder, I average around 3.5% from DOpus. Unless I'm scrolling down to files that haven't been read before. When I do this, and the file's name, size, date modified, etc. need to be read, the use spikes to around 9%. Numbers are similar to a folder with 180 video files, mostly webms and mp4s, and showing size, and the dates modified and created with the relative date bar in the back.
The folders are on an internal HDD drive as opposed to the SSD my OS is on.
10% CPU usage doesn't seem too much when doing a lot of work. That probably indicates the bottleneck is elsewhere (either in the GPU / display driver, or something is waiting on another resource like disk or memory, but those shouldn't be much of a factor with a cosmetic option).
Grid lines, especially with alpha blending (which is still very slow compared to other operations in Windows) will inherently slow things down a little, but should not make things unusable, so I'm not sure what's going on here really.
From what you say, it was working fine at first and then got slower. Something must have changed at that time.
Windows 10 updates have been known to trash display drivers, even when they look like they are still installed, so that's one possibility, but I'm not sure that explains what you're seeing since it sounds like it has happened with two hardware setups now.
I upgraded my CPU between then and now, but haven't upgraded my GPU. I have been regularly updating my GPU's drivers with the manufacturer's program.
The time when things were going well was after I first installed DOpus last year. I just tried getting used to having no lines in my lister. Coming back to this thread and seeing this reminded me to try testing it out again with my new CPU.
The only time I experienced responsive scrolling performance with the lines was in the early days, and with the old hardware setup. The tests I tried with my new hardware setup were confined to in the last day or so. Performance was laggy. Not as horrible as depicted in the videos, but very jarring compared to the silky smooth performance I get with the lines off.
I do remember having the program on an older desktop computer, but I don't remember how well it performed. The HDD was dying and slowing literally everything on the system to a crawl, so I don't think it would have been a useful datapoint.
