performance issue when erasing segments of long textured strokes

[blt-r]

Describe the bug
It looks like each texture piece on the stroke is recalculated when the stroke is split/shortened with eraser. It causes performance issues when modifying long strokes and when erasing a stroke from the "start" it kind of shifts the texture along the stroke which is probably undesirable.

To Reproduce

1. Draw a strike using textured brush
2. Use "split strokes" eraser to split/erase the stroke.

Expected behavior
It probably shouldn't recalculate the position of each texture piece when stroke is modified.

Screenshots
Screencast from 2023-06-29 22-08-18.webm

Desktop (please complete the following information):

• OS: Arch Linux
• App Version: Rnote v0.7.0
• Installation Source: Flatpak
• Desktop Environment: [e.g. Gnome 44.2]

Additional context
One time when I was trying to record the screencast with the bug, my whole system froze for 10 minutes and unfroze when rnote quit (probably forced by kernel)

[Doublonmousse]

I think there's two issues here

• when splitting the strokes, keep track of the rng so the downstream stroke doesn't reset/shift
• performance for rendering It's not impossible the first point influences the second one, when profiling it seems the cost comes mostly from the Cairo::context::Context::fill method