Delay in all tools

[Apuntesie2]

Describe the error

  - the error occurs with: `1.7.2” `1.7.3” 
  - the error does not occur with: `1.6.4`.

OS :
- bug occurs with : Windows
- not checked : Linux `macOS

• Installation source: OpenBoard windows distribution repository` download page,

The occurs on several computers

delay.in.all.tools.mp4

[Apuntesie2]

Good morning. Tomorrow I will close the request, since I see that it does not happen to anyone else nor does it seem to have a solution.
Finally, say that I have a wacom intuos BT M and that it doesn't happen with other applications.
Thank you.

[bruening-bw]

There are two delays. The cursor is a little behind and the stroke is a little further behind. This depends on the pen settings. If I change the preview circle size, the delay occurs.

test.mp4

Using default settings the delay is so slight that it doesn't bother me. But with the smaller viewing circle, it feels wobbly. I couldn't clearly determine whether the green line is also more delayed. But it certainly feels that way. Overall, it doesn't feel good in this setting. That's why I don't use a smaller preview circle, like I otherwise would. I also notice a different behavior when I deactivate the pressure sensitivity. However, it's not entirely clear whether perception isn't also playing tricks on me. Because with the settings that I perceive as delayed, the pointer is not displayed during the writing process. Perhaps the delay is less noticeable if the cursor is also whizzing around under the tip of the pen.

I have noticed delays on my ugee U1600, which I tend to link to the hardware and the driver. This possibility also exists and should not be ruled out as a cause in individual cases. However, I made the video on my Cintiq 22. The phenomenon is real and it is OpenBoard. So you shouldn't close the issue. But perhaps it would be helpful if you could experiment a little with the settings and describe the conditions for the delay in more detail. As a user without the ability to contribute to the code, I am very grateful for the work that is being done here. The least I can do is provide as much information as possible.

[letsfindaway]

I did some experiments and found:

• The lag is remarkably larger with Qt 6 than it was with Qt 5.
• The lag can be reduced by only repainting the small circle (or the marker or eraser circle) at let me say every 5th mouse move event.

But less frequent repainting would only be a workaround. I do not see that the CPU limits the repaints with Qt 6, so I wonder what else might cause this. Any ideas?

[bruening-bw]

I tried the Qt5 Version of the deb-package that you made for me to test a few days ago. I can confirm your findings on my system. The lag is less with Qt5 but it is still annoying.

I know somebody to ask. But he might be pissed a little. I have to make a phone call. I'll report back.

[Apuntesie2]

Good afternoon.
I would like to help solve the problem but I lack technical knowledge.
I simply want to reiterate my gratitude for your dedication to this magnificent program.
All the best.

[letsfindaway]

I was now measuring the time between mouseMove events:

• For Qt 5: About 7 ms between two consecutive events.
• For Qt 6: About 33 ms between two consecutive events.

So the time is about 5 times longer with Qt 6, which leads to larger lags. Now I'm searching for some way to adjust the interval for Qt 6....

Edit: I get the fast events in Qt 6 if I disable any GUI update in the mouseMoveEvent handler. So it seems to have to do with painting in the event handler.

[letsfindaway]

Next step: I created a minimal program for drawing on a QGraphicsScene. This achieves a time between two mouse events of 7 ms on Qt5 and Qt 6.

I also removed the call to inputDeviceMove in OpenBoard, UBBoardView so that we skip any drawing in the mouse event handler. Then we also achieve a time of 7 ms between events using Qt 6.

That means the longer times are not a general property of Qt 6, but is affected by what we do in the event handler. And: it is not a general problem to do some drawing in the event handler. It seems to be something specific.

Further finding: The mouse events occur more often (every 16 ms) when I do not emit painted() in UBBoardView:1839.

[letsfindaway]

There are two delays. The cursor is a little behind and the stroke is a little further behind.

IMHO, the first delay (cursor behind the pen) is out of control of OpenBoard. The cross cursor is a system cursor and is not controlled by OpenBoard. It is drawn by the operating system just like any other cursor. If this is behind the pen, then we cannot do anything about it.

The second delay (stroke or preview circle behind the cursor) is caused by the low repetition rate of MouseMoveEvents as described in my previous comment. The small circle is painted by OpenBoard, so it is already affected by this. The stroke or the small circle should have the same delay behind the pen.

I'm still searching for the cause of the low frequency of the mouse move events, but currently have no convincing idea where I can look further.