By the way, something you definitely should do is go into the General: Warnings options tab, and set the option to show logging, then relaunch. That will help you see if there are excessive tasks going on when clicking on things.
It is expected to see a fair amount of activity, particularly if you right-click on folders. It will load content files for the associated items you click on, and there is perhaps some optimisation we could do here to make some of this better—but in most cases we’d be talking about shaving off microseconds from the click event. So while quantity might be alarming, what is normal is a bunch of four-line groupings related to the loading and parsing of RTF files. Abnormal logging would involve warning or error lines.
Qt libraries have a UNIX heritage. Also the Qt graphical elements (buttons, dialog boxes etc.) were originally designed to work with X-Windows. Hence WSL, hence graphics or graphics libraries could be a problem.
There may be some translation library which is not quite right For example maybe a mismatch between versions of OpenGL or even registry entries. So Scrivener could be making a system call to an OpenGL routine which is not supported by the driver and it takes Windows three seconds to figure it out and do it a different way. It may even be switching between graphics cards to accomplish the task.
Installing WSL might ensure that all the proper libraries that Qt needs are correctly installed and updated. As I said, a long shot.
I have used lots of software ported from Linux and MacOS to Windows. Often problems with graphics and lag are caused by using things like Qt instead of programing natively to the Windows API. The situation is far better today but in the past sometimes Qt based programs were laggy in addition to having buggy graphical elements. Things like TexStudio, for example, were unusable.
The graphics libraries are probably not the problem, but who knows.
@logaandm: Qt libraries have a UNIX heritage. Also the Qt graphical elements (buttons, dialog boxes etc.) were originally designed to work with X-Windows. Hence WSL, hence graphics or graphics libraries could be a problem.
I’m not sure how much of an impact the latter would have on the former, as a Qt build is rather self-contained (one of the criticisms, as it produces bulky installations). I don’t think it’s going to be looking for a Linux subsystem anywhere on purpose or be able to do anything with it. I could be wrong, but that would seem to go against the cross-platform nature.
More salient to the point here though is that the user indicates Scrivener v1 suffers no performance issues. Seeing as how both are written in Qt/C++, it’s unlikely to be an issue related to that itself.
I would lean more toward contextual problems, which is why I suggested running some tests with empty projects. Right-click can in some cases fire off a lot of disk activity in larger projects.
That’s something @flange could try in fact: give the most recent Scapple beta a test. It is also using the more modern coding libraries, so any deep issues related specifically to the toolkit should be present there as well.
I created 8 chapters (as folders) and two to three empty sub-chapters in each — no issues with the lag.
I then copied some random plain text with ~7k words and pasted into each created sub-chapter — no issues with the lag.
I then pasted the same text, making a few sub-chapters to have 14k or 28k — issues with the lag started to happen when switching between these larger sub-chapters, but not that much, I’d say it’s workable.
I then created about 10 inspector comments (nothing but the default text in it) in these larger sub-chapters — issues with the lag then became considerable, I’d say unworkable.
I should also mention that I’ve tried this on 3 different computers with the same results, and also to remind that Scrivener 1 has no such issues.
@NaOH: I then created about 10 inspector comments (nothing but the default text in it) in these larger sub-chapters — issues with the lag then became considerable, I’d say unworkable.
Yeah, I can see that happening, though for me it requires the inspector to be open, which likely means the issue has to do with building the comment box interface. If I close the inspector then clicking between items with lots of comments in them is swift. Likewise, opening and closing the inspector takes a couple of seconds under this condition.
I’d be curious to see if any of these conditions are necessary for the original report as well.
I tried what you said, but in my case, I had to relaunch Scrivener to have any effect. I wouldn’t say clicking between items became swift, but workable. Although, my project is large. On the other hand, if Scrivener 1 can handle it swiftly, so does Scrivener 3. I’ll just wait for newer version of Scrivener 3 before buying it (I also expect to see texture background option for the main editor, otherwise I’ll accuse L&L for treating windows users as second-class citizens )
)