Typing latency issue

[friendmind]

Ever since I've update to the new version I have been having issues when typing. As I type, the words do not appear on the screen in sync with my typing. It takes a couples seconds before the words I've typed up show up. I've tried uninstalling and reinstalling the application and still have the same issue. I've tried novelWriter in another computer and still experience the same latency.

I have reinstalled the earlier version I had which was novelwriter-2.5.3 and I am having no latency issues when typing.

I don't know if this is only happening to me but thought I'd ask just in case I am not the only one facing this problem.

Version info: NovelWriter 2.6.1 Qt 5.15.13

[vkbo]

Is this the same issue reported in #2129?

What operating system are you running on?

Edit: Also, what font are you using, and is it the same on both computers you tested?

[vkbo]

I've done some further investigation in the mean time, and I think I may have found the cause. It seems that this is related to the word count update, which causes a lot of changes in the project tree. The word count updates every 5 seconds when you're typing. Is there any indication that the lag is related to that update?

I noticed that when the word count updates, it triggers a whole cascade of updates in the project tree. The vast majority of these are likely unnecessary, and they may clog up the processing queue on computers with less resources. Unfortunately for these kind of issues, I'm running on a very fast computer, so I'm not really noticing these delays. It makes it harder for me to debug it in this case. But I can try to limit the amount of updates to see if it fixes the issue.

The project tree code was completely rewritten for 2.6, so it's likely that this is the issue. Specifically, it was added in 2.6 Beta 2, so you can also try to run 2.6 Beta 1 to see if the problem exists there. It probably doesn't.

[friendmind]

Now that you mentioned it, yeah the latency happens after writing a lot every one or two minutes. It appears it refreshes the page or something.

My OS is Windows 11. The font I'm using for the document is 18pt Calibri Regular for both computers.

I looked at the issue report you provided above and saw that I have most of the features mentioned currently turned off. I've also gone in and tried 2.6 Beta 1 as you said and I am still finding latency issues.

[vkbo]

Dammit. That basically rules out my hypothesis, not confirms it. The word counter runs every 5 seconds when you're actively typing. You can see when because the word count in the project tree should update. Also, since you see the issue in 2.6 Beta 1, the project tree is not the cause, as the project tree code was rewritten for the Beta 2.

The problem does seem to be a Windows issue primarily though, so I'm back to suspecting it has to do with the rendering of the text on the screen. Maybe there's some graphics acceleration issue here.

I will investigate further.

[friendmind]

Not sure if this is of any help but I have reinstalled version 2.5.3, which was the version I had prior to updating, and have experienced no latency issue.

[vkbo]

Yes, you already mentioned that, so that's the one I've been comparing against. I'll try to figure out what change causes it.

[peter88213]

I'm running on a very fast computer, so I'm not really noticing these delays. It makes it harder for me to debug it in this case.

Perhaps this can be reproduced using a VM? I once experienced comparable problems with tkinter (redrawing window content with changed scale when the window is resized) via a VM. What ran completely smoothly natively under Windows 11 was extremely sluggish under xubuntu/VirtualBox.

[vkbo]

Perhaps this can be reproduced using a VM?

I can't really reproduce it there either.

As mentioned in #2129, I already tested if the code that is injected on every keypress is the issue, but I don't think it is. Even on a slow VM, and with everything enabled, it doesn't take a lot of time to process.

I've also considered whether it is a rendering issue on the Qt side. There are some reported cases where even the simplest example editor has caused lag on Windows, so there may be something to that. However, that doesn't explain the difference between the 2.5 and 2.6 releases. I'm not entirely sure how Qt renders text at the lower level, but if I type very fast (like mashing many keys kind of fast) I do get a lag on my setup too.

One thing I am investigating is the switch from using Qt's regular expression engine for processing highlighting to using Python's own re package. If I can reproduce the issue, I can test for this.

Of course, each new release also potentially pulls a new version of Qt, and there could be differences there too, which I will look into as well. This is not a trivial one to debug, that's clear.

My suspicion with the word counter comes from my rewrite of the project tree from using a standard tree widget from Qt to a proper model/view setup. Since the model is implemented in Python, it will naturally be slower than the pure C++ implementation in Qt, but I've also made a bunch of optimisations. Still, it is called thousands of times when changes are made, including word count update.

[peter88213]

Well, in my case I suspect the additional graphics layer with which the Xubuntu screen is displayed in the VM under windows. Would it help with novelWriter to deactivate the live-wordcount via a switch for test purposes?

I have an optional section editor for my novel organizer whose live word count works locally at first, i.e. only on the editor status bar. Changes must be explicitly accepted by the user, and the changed word count then effects all other views.

This reminds me: can you possibly reproduce the OP's problem by editing an extremely large amount of text at once? If it is due to the regex algorithm, small sections will of course help.

[vkbo]

It's lag while typing, not editing, so it will only apply to the current line at any given time. To the extent I can reproduce anything like it at all, switching off the internal features running on typing or timer don't seem to make a difference.

In #2129 turning off some features helped somewhat according to the reporter, but that could simply be that the delay crossed under the threshold of their typing speed, thus no longer accumulating events to be processed in the queue, this no lag.

[peter88213]

If it helps: I fixed my problem by calling my redraw method immediately instead of pushing it to the queue. Then I introduced a semaphore that prevents the calls from accumulating on the stack. This way the program always keeps up with user interactions.

[vkbo]

I don't think I have that level of control over the text editor. All of the painting happens in the Qt text layout engine in the library. I can prevent new things to get added to the main GUI event queue, which is the word counting update, but that's about it.

[peter88213]

Well, for me it's tkinter, where of course you have to do a lot more yourself. The trick here is to force a complete processing of the queue before each redraw call. This gives redraw an instant start, and if the semaphore is still set, it returns immediately.

Perhaps there is an equivalent to the tkinter update() command in qt? Then you could call it up before the word count.

The semaphore is a Boolean variable that is set at the beginning of the time-intensive algorithm and reset after completion.

[vkbo]

Just tested in my Windows 11 VM, both with the 2.7 Alpha package and the 2.6.1 package, and I could not reproduce any lag other than the brief delay when outright mashing tons of keys, which will cause a delay in the keyboard/usb/whatever layer itself.

It is nearly impossible to debug an issue that I cannot reproduce, so I'm at a loss.

[vkbo]

Version info: NovelWriter 2.6.1 Qt 5.15.13

Hmm, I just double-checked this.

On 2.5.3:

[2025-02-16 14:34:43,362]          guimain.py:94    INFO      Qt5: 5.15.2 (0x050f02)
[2025-02-16 14:34:43,362]          guimain.py:95    INFO      PyQt5: 5.15.11 (0x050f0b)
[2025-02-16 14:34:43,362]          guimain.py:96    INFO      Python: 3.12.7 (0x030c07f0)

On 2.6.1:

[2025-02-16 14:37:27,382]          guimain.py:95    INFO      Qt5: 5.15.2 (0x050f02)
[2025-02-16 14:37:27,382]          guimain.py:96    INFO      PyQt5: 5.15.11 (0x050f0b)
[2025-02-16 14:37:27,382]          guimain.py:97    INFO      Python: 3.12.8 (0x030c08f0)

So, it's a different Python version, but the Qt libraries should be the same. Where did you see Qt 5.15.13?

[vkbo]

On a different issue, fonts came up as a possible cause of slow UI responses. Especially on Windows. If you can still reproduce the problem @friendmind, could you check if it improves if you pick other fonts? Possibly a font without any additional styling, like Calibri Regular.

[vkbo]

Any change on this issue after the release of 2.7?

[vkbo]

Closes due to lack of response and no way to verify.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or feature requests.