Memory usage skyrockets when doing anything in Pinta

[khoidauminh]

To Reproduce

1. In Pinta, select a brush/pencil tool and start drawing;
2. Keep drawing and watch as its memory usage goes up.

It's also possible to cause the memory usage to go up by just zooming in and out of the canvas, selecting random places in the canvas, etc. But drawing usually drives the RAM usage up the most.

Additional Info

pinta.mp4

Commit that introduced this regression: #685

[badcel]

Can Confirm on Fedora 40.

[cameronwhite]

Confirmed on macOS as well.
If I launch Pinta with the --debug flag, which forces the GC to run very frequently (https://github.com/PintaProject/Pinta/blob/master/Pinta/Main.cs#L107) then I didn't observe any major memory growth, so that might be a good starting point for investigation

[potatoes1286]

Debug flag does seem to fix it from me (I had been seeing >10GB ram usage just adding text!), however even with debug on it still experiences heavy >3GB ram spikes with accompanying lag spikes when zooming in extremely low.

[cameronwhite]

That might be a somewhat separate issue - the canvas renderer isn't as efficient when zooming in after the port to GTK4 since we can't do partial redraws of only the visible area.
But it could also be related somewhat to the GC issue if the Cairo.ImageSurface used by the canvas isn't being collected quickly enough, since the Cairo.ImageSurface binding doesn't currently inform the GC about the native memory size it represents.

[cameronwhite]

Just recording notes from my investigation:
Adding an explicit context.Dispose () at the end of PintaCanvas.Draw()

Pinta/Pinta.Gui.Widgets/Widgets/Canvas/PintaCanvas.cs

Line 148 in ebf0335

private void Draw (Cairo.Context context, int width, int height)

fixes the vast majority of the memory usage increase

This particular Cairo.Context likely has a big effect on memory usage since it can be the last reference to a temporary Cairo surface from the GTK widget (https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gskrendernodeimpl.c#L3495)

We can make this fix in Pinta once there's a new gir.core release with the fixes for gircore/gir.core#1109