memory leak fixed(?)

[d-buchmann]

Fixes #11

• don't use Pango.CreateLayout per Draw/MeasureText call
• I'm not a GTK expert, just figured out that this constellation doesn't seem to leak

[hol430]

I'm still seeing the problem after applying this patch - memory usage seems to stay more or less constant for me, but CPU usage goes to 100% and the application freezes. This is what I've observed with this graph on the master branch as well. I've tried the net452 version on your branch, as well as a netcoreapp2.1 and netcoreapp3.1 versions from my branch. I really haven't done any debugging yet - it's not a huge problem for us because we don't do this sort of rapid redrawing in our application. But I might do some investigating when I get the chance...

[d-buchmann]

I suppose you are using some obscure arch like armhf? ;))
That's where I cannot make the PlotController Example work either - on x86_64 the whole ExampleBrowser works fine.

Our own application works fine on both platforms, netcoreapp3.1.
But there's one hoop I had to jump through: All plot updates/invalidations must be made using GtkWindow.TickCallback, not within their own Something.Timer.Timeout. For me that prevented application freezes completely, even though we're doing "quite frequent" (10Hz) redraws.
But as I haven't found a root cause, I don't know how/where to file this as a bug/fix, although I'd like to...:)

[hol430]

Actually, I'm seeing it on x86_64 :). I'm on linux/x11 and what I'm seeing is thousands of enter-notify and leave-notify events firing as I move the mouse over the "Show tracker without clicking" example. This causes the application to become unresponsive (as the main thread is very busy).

The problem appears to occur when the tracker label and its eventbox parent are moved in the ShowTracker() function. If I comment out the line that actually moves the label's parent, the plot actually remains responsive despite continued calls to the motion-notify-event. My guess is that moving the tracker (gtk_layout_move()) is somehow causing further enter-notify and leave-notify events to occur, even if it's only called from the motion-notify event.

But there's one hoop I had to jump through: All plot updates/invalidations must be made using GtkWindow.TickCallback, not within their own Something.Timer.Timeout

Yeah, we do something similar (using Gtk.Application.Invoke()). Making gtk API calls from a background thread is not supported, and will usually lead to unfortunate results. But I don't think that's the problem in this plotcontroller example, as everything is occurring on the main thread (as far as I can tell anyway...).

The part that really surprises me is that this example graph is working for you :). Are you testing this on windows?

[d-buchmann]

Yep, the OS was the crucial piece of missing information :)
I'm using Windows on x86_64 and Linux on armhf, but after your comment, obviously the arch is not an issue but rather the OS / OS-specific implementation of Gtk.

Anyway, I consider my specific original issue solved, and would rather open a new one for the "application freeze on tracker move event in linux" or something...what do you think?

[VisualMelon]

@d-buchmann It certainly does look like a problem with layouts leaking:

I'll try to remember to take a proper look at your PR next weekend, but it looks sane and from a quick test it seems to mitigate the problem (tested with the .NET Core GtkSharp (can't use the old one))

@hol430

I'm still seeing the problem after applying this patch

Were you only observing memory issues with the tracker example, or also with other examples? Can you provide any diagnostics if so that might help narrow it down? (I'm not in a position to test with Linux at the moment).

The part that really surprises me is that this example graph is working for you :). Are you testing this on windows?

FWIW, I am able to use the tracker example just fine on my Win10 box with the .NET Core GtkSharp (can't test the old one).

Feel free to open another issue for the tracker problem if you think it's not directly related.

(sorry if I'm asking the wrong questions to the wrong people; not sure I'm quite following the conversation)

[hol430]

Sorry for the confusion - my tracker issue is almost certainly not related to the memory leaks, so I'll create a separate issue.

[VisualMelon]

Can you add an entry to the change-log for this including the original issue id? E.g. "Fix memory leak in GraphicsRenderContext (#11)"

I'll merge this as soon as that's done.

[VisualMelon]

(That said, it looks like we should be disposing the contexts, but it's not obvious how or when, and since this largely mitigates the problem without any design work I think worth merging now rather than waiting)

[VisualMelon]

@d-buchmann merged; however, AppVeyor is unhappy. I'm assuming it's a GTK version issue because #10 is fine. I'm tempted to merge #10 despite the loss of .NET 4.5 (4.6 is as old as Win10), but if you have any other bright ideas, or had to mess with your machine at all to get this to build, I'd be keen to here them.

(Scratch that, #10 wasn't re-run; and doesn't make sense, because it's not GTK3 that is failing.)

[VisualMelon]

OK, this has definitely broken GTK. @d-buchmann which version of GTK# are you using? I can't find one newer than 2.12.45; we may have to make this compilation conditional.