Artifacting when drawing, selecting, dragging, erasing, etc.

[wayfarren]

Describe the bug
Any form of movement on the canvas results in artifacting, generally wallpaper artifacts, but sometimes artifacts from the eraser or selection tool. The main brush will also often default to selection, but it's not consistent. I feel like this is related to the other issue, because if my memory serves me correctly, I didn't have these issues a couple of months ago. I feel like either a system update or a rnote update created this issue.

To Reproduce
I'm not sure how to reproduce this behavior. My apologies.

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

Console Output
(I don't know how to get this, I didn't install rnote with flatpak, sorry)

Screenshots
Here's a screen recording of the artifacting. Note that it also occurs with the red border of the eraser tool.

https://github.com/user-attachments/assets/a246d338-a301-44fe-9c75-8759f9fba9d6

Desktop:

• OS: Arch Linux v6.11.4 (using linux-surface)
• App Version: Rnote v0.11.0
• Installation Source: Arch Linux Official repo, I also tried building from source, but the problem wasn't fixed
• Desktop Environment: Hyprland v0.44.0
• Display Server: Wayland
• Input Source: On-Screen-Tablet (Microsoft Surface Laptop Studio)

Additional context
This issue seems very similar to #309

[rightleftspin]

I'm getting this same issue after updating an hour ago. My specs are as follows.

OS: Nixos Unstable App Version: Rnote v0.11.0 Installation Source: Nixpkgs, recently updated Desktop Environment: Niri 0.1.9 Display Server: Wayland Input Source: Wacom Tablet

[devraza]

I'm getting this issue too, using version 0.11.0 on Hyprland on NixOS. I'm using a Huion tablet as my input device.

[ibesmrad]

I have this issue too in both Hyprland and KDE(with Wayland) and using the latest version of rnote.

[sodiboo]

I'm also experiencing this issue on 0.11.0 on NixOS with niri.

The problem is with damage tracking, and only happens with a fractional scale. Somewhere, the damage region is likely rounded to surface-local coordinates (which are integers; one fundamental flaw of the core Wayland protocol that unfortunately cannot be fixed), which is wrong and causes off-by-one errors like this. I couldn't easily find the offending code from a quick search for damage in this repo, which yields zero code results.

The correct way to implement this is to ignore the surface-local coordinates. Because damage is inherently unrelated to surface geometry, there exists a damage_buffer requests on wl_surfaces, which should be used instead. Then, the damage never needs to be rounded and doesn't cause this issue.

The issue doesn't occur on integer scales because then the rounding is exact.

It seems to be the case that every buffer from rnote is an empty buffer with transparent pixels. This issue would be less noticeable if the remainder of the buffer was also content, because then the only effect is that the GPU does slightly more work than necessary. Because the region that wasn't drawn is transparent, it causes the parts that were not drawn to update to a transparent pixel instead. It is part of the surface's opaque region, so most compositors will show the incorrectly damaged parts as black, unless you have a window rule making the whole window transparent, in which case it will show your wallpaper or whatever's behind.

Panning removes the artifacts because it redraws the entire buffer and damages the entire buffer.

[dangooddd]

I have this issue too, with any level of fractional scaling. Without fractional scaling issue dissappears. Runnig on KDE Plasma 6.2 Wayland

[wayfarren]

Ah, that explains it. kinda sucks, because fractional scaling is the only thing that works properly on my laptop due to it being a high dpi screen. normal scale value and everything is too small.

[devraza]

@HenriHawk42 have you tried a scale of 2?

[wayfarren]

@devraza the scaling appears too large for my laptop (i.e. the buttons are too big)

[Kneemund]

I've tried to reproduce this, and I'm getting these artifacts everywhere when fractional scaling is enabled (e.g. when hovering over elements of the workspace browser), not just within the canvas.

Rnote doesn't interact with Wayland directly, but sodiboo might still be on the right track. It could also be a GTK, mutter or cairo bug (or any other abstraction we use); fractional scaling is experimental after all. I'm not sure, I'll try to do some more testing soon.

[sodiboo]

Rnote doesn't interact with Wayland directly

Yeah, i wasn't able to find much Wayland-specific code. But i am approaching the issue from the perspective of a Wayland compositor (as that's the thing i'm to some extent working on), so i described what is definitely happening at that level.

The actual location of the bug is at some higher level of abstraction, but fundamentally it does look like it's incorrectly rounding the buffer damages to fractional scales (which again, is wrong and unnecessary, because even at the lower level of the stack you are supposed to pass the raw buffer damage, so it shouldn't be rounded anywhere along the chain of custody)

[wayfarren]

switching to an integer scale factor fixed this issue perfectly for me, and this is honestly better because the buttons are bigger for ease of touch. only downside is that other apps are scaled incorrectly. i wonder if i can somehow tell hyprland to use 1.6 scaling for other apps but to use a scale factor of 2 for just rnote

[devraza]

@HenriHawk42 maybe you could have a script running that changes the scale factor depending on whether you've got focus on rnote or not.

[wayfarren]

yuhp, i was thinking that myself

[Doublonmousse]

I thought GDK_SCALE=2 would work as a workaround but that isn't activated with the wayland gtk backend (but works on X). Maybe GDK_BACKEND=x11 GDK_SCALE = 2 rnote is a passable workaround.

Also, what versions of gtk are you on ? ~~I can't seem to reproduce this on 4.16.5-2.fc41 with fractional scaling on kde (no matter the renderer, though I know there's a fedora specific patch here, probably unrelated though).~~

Edit : It still happens with the gl renderer (also applies to the general UI outside of the canvas !), sometimes but less with the ngl renderer and on vulkan I'm not sure (I have a lot of artefacting in some cases but of a different kind, though I'm not sure how specific to my machine this is, I'm on asahi)

[devraza]

Just GDK_BACKEND=x11 was enough to fix the artifacting for me, though the UI still appears blurry/pixelated.

[chronically-late]

I'm having the same issues on a Thinkpad X1 Tablet Gen 2.

Arch 6.13 Desktop: Sway/Wayland Rnote version: 0.11

The issue first appeared on commit 7e1b3861120199ca02795810ebe63185f50131b1.

PS: Bisecting Rust applications on weak hardware is no fun at all...

[Doublonmousse]

@chronically-late If it's this commit, could I know what version of gtk you're building with? From the package manager, the meson setup output or using GDK_DEBUG=interactive rnote

If you build with a commit before this one, running

GSK_RENDERER=gl rnote

will have the issue and

GSK_RENDERER=vulkan rnote

or

GSK_RENDERER=ngl rnote

will not (and if the last command doesn't work you're probably on gtk 4.17.x). The issue is a gtk4 one and this may have been fixed on some of the renderers on more recent versions. The bisected commit is us forcing one of the renderer because it was unstable when first introduced as the new default

[chronically-late]

@Doublonmousse My gtk version is 4.16.12 and you are correct. Setting GSK_RENDERER=gl rnote for a build from a commit before https://github.com/flxzt/rnote/commit/7e1b3861120199ca02795810ebe63185f50131b1 will introduce the issue while vulkan and ngl work fine.

Edit: Is the hardcoded environment variable really necessary? Couldn't you set env GSK_RENDERER="gl" rnote in the .desktop file? That way people could switch to vulkan if they experience this issue without having to recompile.

~I've now just changed the line from the commit to vulkan in my 0.11 build to fix it for myself at least, that's enough for me until the gtk4 issue is fixed or Arch receives a newer version.~ Too unstable.

Edit 2: I just noticed gtk 4.17.4 in the Arch gnome-unstable repo, might just give it a try to see what happens.

Edit 3: Building against gtk 4.17.4 fixes this issue, but it's still very unstable.

[Doublonmousse]

@chronically-late Thank you for testing ! I think changing if/how we force the renderer will have to wait for the 4.18.x release to roll out (so that we can force the gtk4 version to be >=4.18 and change settings without breaking things on older versions)

[SeeStarz]

Hi, I'm using arch linux with hyprland and is having a similar issue when using fractional scaling (a lot of artifacts when drawing and some just appears randomly). Weirdly, the flatpak version does not seem to observe such behaviour? Also, this issue does not seem to happen when rnote is on fullscreen and reappears when it exits fullscreen.

[cleanerspam]

So is their no workaround for these artifacts , maybe rnote should switch to QT , it is always GTK that causes weird bugs everywhere in each updates. I do not face this issue in Xournal++ but it has all the pen and color hidden inside menu requiring several steps whereas rnote has everything mostly needed one click away but these glitches makes it unusable

[chronically-late]

@cleanerspam You could either use the Flatpak version @SeeStarz mentioned or you could disable scaling for the output you're using rnote on. Sadly, both the vulkan renderer as well as gtk 4.17 are too unstable to use them (rnote will crash after a few pen strokes).

Also, the comparison to Xournal++ is unfair, it's written in C++ using gtk3/gtkmm, which is decades old, while gtk4/gtk-rs is fairly new and the rust-qt binding would probably cause similar issues.

[Doublonmousse]

@chronically-late Can you retest this on gtk 4.18.2 ? As 4.18 is the next stable this will affect us (if we should bump the gtk dependency now or not, and other people will be affected as well on the stable versions once new distros are updated to gtk 4.18).

The gl renderer isn't part of 4.18 anymore (there is only ngl and vulkan now with the latter as the default on linux)

If it still happen, it'd be good to open an issue upstream on the gtk gitlab page (with backtraces if possible : if RUST_BACKTRACE=1 doesn't return anything, then gdb rnote followed by typing bt after the crash and posting the output). We should at the very least report gtk issue upstream so that they can (hopefully) be fixed.

As for the UI framework, for gtk4 the bindings rarely were an issue. Qt isn't very used with rust (there's a few projects but maybe not mature yet or maintained?)

There isn't really good alternatives outside of these two for now for our use (we absolutely need good pen and touch support and a good enough reason to switch if we do so for what we'd want to do with the interface, rendering, cross-platform support, general stability etc... And time to do so as well)

[chronically-late]

@Doublonmousse Tested with glib-2.0 2.84.0, gio-2.0 2.84.0, cairo 1.18.4, gtk4 4.18.2, poppler 25.03.0, poppler-glib 25.03.0, appstream 1.0.4 and libadwaita-1 1.7.0 on current git (fb85009f11d6339811b4b4bbe0e52463609fcf52) Artifacts are still gone, but rnote crashes after 2-3 strokes with ngl or vulkan.

[Doublonmousse]

@chronically-late Do you have any terminal log from using RUST_BACKTRACE=1 (and if not, can you run gdb rnote then typing run, reproducing the crash, typing bt in the terminal and pasting the output) ?

This would facilitate a lot debugging (and make it possible to open an issue on the gtk side)

[chronically-late]

The crashes are hardware/setup related and have nothing do to with this issue.

I've always tested this while connected to a USB-C dock with external display for power. I just found out that with the tablet running on battery or normal USB-C power adapter it seems to run nice and stable.

I've also tested with a Wacom One Tablet on a 3 display setup and the problem does not occur. I'll retest this with diffrent scaling values and report a bug if I can narrow it down.

[chronically-late]

FYI: Arch has moved gtk4 4.18.3 from testing to extra a couple of days ago.

[Doublonmousse]

@chronically-late is there any logged error in the terminal or does your scaling value is 170 % ? Also 0.12 is out with gtk 4.18 so you can test the new version

[chronically-late]

@Doublonmousse Sorry about the delay. My scaling factor is 140% for eDP-1 and 120% for DP-1 (the external 3440x1440 USB-docking monitor that was causing the crashes, which don't happen anymore with 0.12 and gtk 4.18) and everything works as it's supposed to, terminal only reports some MESA/vulkan "FINISHME" warnings.

So I think this can be closed.