Writing zip-zap when writing with tablet

[LumenYoung]

Describe the bug
A clear and concise description of what the bug is.

As you can see in the following picture.The stroke experience very large zip-zap in normal writing

To Reproduce

I didn't know how to back to the normal state, so I don't know how to reproduce. Therefore I seek for help in order to diagnose the problem

Expected behavior
A clear and concise description of what you expected to happen.

** Console Output **
Run the app in the terminal with flatpak --env=RUST_LOG=rnote=debug --env=RUST_BACKTRACE=1 run com.github.flxzt.rnote and post the output

This is the debug log right after I spot an occurrence of the zip-zap:

rnote_debug.log

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Archlinux
• Installation source: AUR
• Desktop Environment: KDE 5.27.1 on wayland

Additional context
Add any other context about the problem here.

During the trouble shooting, I have seen the followings:

1. I won't experience this problem when drawing using mouse
2. Changing different pressure curves doesn't help
3. No problem with excalidraw and xournalpp drawing with the same tablet, which indicates that is a rnote only problem
4. I tried to disable both touchpad and mouse. The tablet is the only cursor manipulator, and the problem still exists.

Following are additional screenshots.

[flxzt]

Could you provide either the rnote document or a selection from it? I have the suspicion that this has the same cause as #524 but I would need to inspect it to confirm.

Edit: Also I believe the package in the AUR is outdated, please upgrade to v0.5.14

[LumenYoung]

Thanks flxzt for the quick reply. Yes I can provide you with the document. I did realize that it is not from aur but directly from the arch community repo, so might not be the problem from out-of-date package

The following is the file with jpg extention (github don't let me upload file with .rnote extension xd):

[LumenYoung]

Could you provide either the rnote document or a selection from it? I have the suspicion that this has the same cause as #524 but I would need to inspect it to confirm.

Edit: Also I believe the package in the AUR is outdated, please upgrade to v0.5.14

I've checked the #524 and it looks quiet similar. So I'll switch to the rnote-git to test out if the problem is solved already

[LumenYoung]

I've tested the git version of rnote (0.5.14.r9.g0f748391-1) and the problem presists

I do notice that the zip-zap is much less frequent. But still exists.

[flxzt]

Just to document it: I tested some things with xournal++ on wayland and also got similar glitches occasionally:

Fedora 37, Wayland, Xournal++ 1.1.3 flatpak
So this seems to be not rnote specific but somewhere else in the stack related to pointer input (or both apps misbehave in the same way, which actually isn't too unlikely given both are processing raw gdk events)

[joshkraan]

Hi, I've been having the same issue since updating to Rnote 0.5.14. Going back to 0.5.13 seems to fix the issue.

My info:

• OS: Arch Linux
• Installation source: Arch community repository
• Desktop environment: Sway 1.8.1 (wayland)

In the attached screenshots the only thing that I have changed on my system is downgrading Rnote. Some things to note:

• The effect is much more noticeable when drawing slowly, but does still occur when writing at a normal speed.
• Each line drawn seems to have a location that the errors all point towards.

[joshkraan]

I just updated to Rnote 0.5.16 and the issue seems to have been fixed for me. Thanks for the great work!

[flxzt]

@OmegaRogue reported similar issues in the matrix room, and was able to record it:

PXL_20230307_082542895.TS_2.mp4

A good observation is that these glitches seem to be "ghost" events, zipping back to the position where the pointer was previously. The video shows this clearly

[OmegaRogue]

I'm currently on rnote 0.5.14, the issue isn't that consistent to reproduce, so I'll update to 0.5.16 and see if it's fixed.
Currently for me the issue happens on my Surface Pro 6 mostly after unlocking it, and only in rnote, it doesn't happen in Xournal++ or other apps, both Wayland and XWayland, restarting the touch/stylus daemon doesn't fix it, only reopening rnote does

[OmegaRogue]

on 0.5.16 it's still here, but less prominent

surfacernote.mp4

[flxzt]

Did you notice a pattern when this occurs? Only as an example, please verify thoroughly: Maybe after using the eraser side / button? Is it consistent to be an issue after returning from sleep, as you mentioned before or is that just a unrelated coincidence?

I am still confused why I experienced the same thing in Xournal++ too (but apparently nobody else). Either it has the same wrong behaviour, or: the input part of Gtk is brittle and didn't change that much between gtk3 and gtk4 wrt stylus input, maybe it originates there. So far I couldn't find any similar bugs reported elsewhere, but stylus apps for gtk & linux are also rare, so it might just be undetected.

Staying in Rnote for now, I would want to log two things:

• the raw incoming gdk events & after translating them into rnote event types ( pen style, pen mode, coordinates, etc.)
• the coordinates right before they are committed to the stroke. To make it clear when such a zip-zap happens

Then I'd be able to narrow it down, if a pattern emerges.

But since those logs are very verbose, I didn't include them yet. I could add them as info level logs and ask you to either run the app in the next beta with --env=RUST_LOG=rnote=info or if it is possible to build directly from git from a branch where I added them.

[LumenYoung]

Did you notice a pattern when this occurs? Only as an example, please verify thoroughly: Maybe after using the eraser side / button? Is it consistent to be an issue after returning from sleep, as you mentioned before or is that just a unrelated coincidence?

I am still confused why I experienced the same thing in Xournal++ too (but apparently nobody else). Either it has the same wrong behaviour, or: the input part of Gtk is brittle and didn't change that much between gtk3 and gtk4 wrt stylus input, maybe it originates there. So far I couldn't find any similar bugs reported elsewhere, but stylus apps for gtk & linux are also rare, so it might just be undetected.

Staying in Rnote for now, I would want to log two things:

* the raw incoming gdk events & after translating them into rnote event types ( pen style, pen mode, coordinates, etc.)

* the coordinates right before they are committed to the stroke. To make it clear when such a zip-zap happens

Then I'd be able to narrow it down, if a pattern emerges.

But since those logs are very verbose, I didn't include them yet. I could add them as info level logs and ask you to either run the app in the next beta with --env=RUST_LOG=rnote=info or if it is possible to build directly from git from a branch where I added them.

Hi, Flxzt,

I was busy and forgot about this thread. I don't know what assistant you want or any information you want?

I'm willing to help to solve this issue.

[LumenYoung]

Did you notice a pattern when this occurs? Only as an example, please verify thoroughly: Maybe after using the eraser side / button? Is it consistent to be an issue after returning from sleep, as you mentioned before or is that just a unrelated coincidence?

I am still confused why I experienced the same thing in Xournal++ too (but apparently nobody else). Either it has the same wrong behaviour, or: the input part of Gtk is brittle and didn't change that much between gtk3 and gtk4 wrt stylus input, maybe it originates there. So far I couldn't find any similar bugs reported elsewhere, but stylus apps for gtk & linux are also rare, so it might just be undetected.

Staying in Rnote for now, I would want to log two things:

* the raw incoming gdk events & after translating them into rnote event types ( pen style, pen mode, coordinates, etc.)

* the coordinates right before they are committed to the stroke. To make it clear when such a zip-zap happens

Then I'd be able to narrow it down, if a pattern emerges.

But since those logs are very verbose, I didn't include them yet. I could add them as info level logs and ask you to either run the app in the next beta with --env=RUST_LOG=rnote=info or if it is possible to build directly from git from a branch where I added them.

For the question you ask, I think my case would be rather extreme. I currently can't find any solution to stop this issue on my computer. I can give you following information and I have some new discovery w.r.t the problem on my computer

1. It is a tablet only issue. Using mouse don't have problem
2. I discover that the horizontal part of the storke are extremely stable, but when you turn your direction into vertical, the zip-zap starts.

I've experimented that on my canvas for several time, and I attached the file in the attachment so you can see it in detail.

Followings are screenshots. Most of the lines are not stopped, rather a continuous line. But different parts suffered differently from the problem. When you draw along horizontal direction, There are basically not zip-zaps. At my experiment it is zero. you can see in the screen shot how stable there parts are.

But when you turn the stroke to vertical direction, the zip-zap starts immediately within the same stroke.

My test data might be hallucination, because when I further test it with opening another canvas, the problem occurs both on vertical and horizontal lines. But this time the problem turns to: if you draw quickly, it will not suffer, once you slow down the stroke, it immediately blasted. So below.

In conclusion, I don't trust such experiments since the problem occurs in probabilistic way and we human are easy to spot pattern from randomness.

Below is a rnote file but with txt extension

debug.txt

[LumenYoung]

Follow up: I currently switch to the flatpak rnote. I solve the stroke problem. But I also observe something interesting. Whenever I switch to the eraser by shortcut and holding. I can see the eraser zip-zap to a same position like what I observed with strokes.

It seems that such behavior is not only constraint on brush, it is common in several tools but only triggered from time to time.

[LumenYoung]

@flxzt I have got a screen recording for the new similar problem occuring on switching to the eraser event

2023-04-02.17-57-08.1.mp4

I also have a link to upload the full screen recording, which is over 10 MB that GitHub don't allow me to upload. You can find another similar problem (I suspect) at 14s and 18s. The jumping occurs when I use tool to drag the canvas.

https://drive.proton.me/urls/B6ARGV59FR#kpso9kcw44vo

Thank you for your hard work and I hope this might help.

[aselker]

I'm having this issue as well. I'm using Flatpak version 0.7.1, on Debian Sid with Wayland (sway), on a ThinkPad X1 Extreme with a built-in Wacom digitiser in the screen.

It's most noticeable with the eraser tool, but sometimes happens with the brush tool also. It seems to happen most often at the beginning of a stroke.

I haven't noticed the problem in Xournal++.

[noarchwastaken]

I encountered this problem as I tried out rnote today, and it seems like the bug only gets triggered when I move the cursor with the mouse within rnote's window before switching to the tablet.
If I move the mouse outside of the window, for example to the taskbar, tablet input behaves normally.

rnote.webm

[digitalsignalperson]

@noarchwastaken Ah you are totally right! If I launch rnote with my mouse cursor fully away from the window that will open, and never use the mouse within rnote, I don't get the erratic pen jumps anymore. Funny I just had my setup with OBS to try and record the bug when I noticed it wasn't being erratic anymore, and I thought for a minute that running OBS somehow prevented the bug.

The point where the pen is jumping to is the last mouse position, as can be seen in your video briefly around ~0:10. I can replicate this here where I can move the mouse cursor anywhere within the rnote window and that will be the point that new ink/eraser intermittently jumps from. And moving my mouse outside the window prevents the issue again.

I'm thrilled to have a workaround to try using rnote now.

Hopefully this info provides a root cause to make it easy to patch, like to disable the mouse input, or set it's coordinates to -1 or something when pen/touch/tablet in use.