GDI object leak in example cairo_clock (& in DrawingArea) about gtkd HOT 8 CLOSED

I can also reproduce this on linux, calling core.memory.GC.collect() in the onDraw listener seems to fix this so it looks like it's just that the GC hasn't kicked in yet when resizing like a nut.

from gtkd.

I don't have the exact same issue that was discussed here, but I have a similar issue: I'm rapidly calling an onDraw method and very quickly choking my system memory.

Widget.callBackDraw in src/gtk/Widget.d creates a new object to wrap the Context every time it is called, and it seems to me like such a function would benefit from more usage of the 'scope' keyword. Is this kind of an approach a straightforward fix or is that part of the code entirely autogenerated?

from gtkd.

Isn't that use of scope being depreciated?

Also what will happen when the user stores a copy of the Context somewhere and the class is destructed at the end of the callback because it's scope or explicitly deleted?

The callback receives a new context from Gtk every time it's called, so we cant reuse the old one.

from gtkd.

scope: News to me. I haven't seen that anywhere in the docs. I'd trust you if you said it was, though.

Context: That's what I mean; I was under the impression that the Context would be unusable outside of the draw signal call and that it was already UB to pull a reference of the Context from the draw signal callback. If that isn't the case then I rescind all that.

from gtkd.

scope: News to me. I haven't seen that anywhere in the docs. I'd trust you if you said it was, though.

http://dlang.org/deprecate.html#scope for allocating classes on the stack

Context: That's what I mean; I was under the impression that the Context would be unusable outside of the draw signal call and that it was already UB to pull a reference of the Context from the draw signal callback. If that isn't the case then I rescind all that.

It's probably very uncommon but it is possible, it's possible to make it undefined behavior and destroy the d copy at the end of the callback.

from gtkd.

scope: Looks like I'm changing up my code some. >_<

Context: I meant that the Context is just a wrapper object that could be destroyed at the end of the callback, while the GtkContext C object still exists for the GTK system to use. In that sense, if GTK already has it to be UB to increase the reference count of a GtkContext in a callback, such UB would be mirrored in GtkD and negate the need for a user to have periodic GC calls. On the other hand, if GTK doesn't have UB if the user steals a reference to the GtkContext in a callback, then it makes sense to me that such behavior is mirrored in GtkD.

The gist of it: My grey area is that I don't know if it is or isn't UB in just good ole' GTK (I assumed it was, perhaps erroneously).

from gtkd.

Commit ad79895 adds an overload of addOnDraw witch accepts an delegate that uses an Scoped Context. The Scoped Context is destroyed at the end of the scope.

from gtkd.

With the 3.0.0 release the non Scoped version is marked as deprecated.

from gtkd.