Menu
▾
▴
#120 Garbage collection for image
There should be a possibility to have images
automatically deleted when they are no longer used.
Currently, "image delete" causes the image data to be
removed immediately, resulting in an empty rectangle if
the image is used. At the same time, the image will
stay in memory even if no widget uses it anymore.
I'd like to request a command "image autocollect <name>
on/off", which causes the image command to be removed
when the last instance of the image goes away.
Logged In: YES
user_id=79902
Tricky. This is an instance of the general problem in Tcl (on
which Tk is built) of a lack of garbage-collected "named
entities" (like commands.) The problem is that an image
may live on even if nothing in Tk refers to it; consider the
case where you've got a list of images and a program that
operates by periodically switching which of those images is
displayed (i.e. doing basic animation.) It'd be nice to fix this
(and if we did, the feature requested in this FRQ would drop
out in the wash at the same time), but it is definitely tough...
Logged In: YES
user_id=21627
Is it really the case that this is not easily implementable?
It seems to me that images are very well refcounted, by
means of the Image and ImageMaster structures. image delete
knows what all the instances are, etc. So it seems that this
feature would have a straight-forward implementation.
Also, this has nothing to do with garbage collection: As
long as there is a name to it, you cannot collect it, as
somebody may refer to it by name. I propose to switch the
name into a an "unused" state: It can get deleted at any
time. The same approach might not be feasible for commands
in general, but it is straight-forward for images.
Logged In: YES
user_id=21627
Maybe. This would be a deviation from the past, so I'm sure
users will be surprised if 'make install' does that. For
people building binary distributions, there probably needs
to be a target that does the traditional install only, or
they need to invoke altinstall bininstall maninstall but not
idleinstall.
Logged In: YES
user_id=21627
[Sorry. wrong tracker]
Logged In: YES
user_id=33229
I think there's a bug at the root of this, unrelated to the
concept
of garbage collection. See:
/tracker/index.php?func=detail&aid=634864&group_id=12997&atid=112997
Logged In: YES
user_id=79902
Now that bug 634864 is resolved ([image names] doesn't list
deleted images and you can't ask for them, but they're still
in there so that operations like recreating an image from
scratch still work - i.e. the references from widgets have
to hang around and we have to be able to reconnect to them)
could the author (or some of the other commenters) of this
FRQ please decide what they're really after? What does "no
longer used" mean? Once I understand that, I may be able to
move forward with this FRQ...
Logged In: YES
user_id=21627
I would like the image to be automatically deleted if no
widget refers to the image anymore.
Logged In: YES
user_id=79902
At the very least, images would have to be specifically
opted into such a scheme (a number of small images are only
used occasionally in Tk dialogs, but deleting them and
recreating them every time seems daft.) Then there's the
question of whether an image should be deleted when its
refcount is zero, when it drops to zero, at an idle time
when it drops to zero, or at an idle time after a grace
period after it drops to zero. :^)
The real complexity comes when you start to think of passing
images around by unhooking an image from one widget and
hooking it up to another. This sort of thing might happen
in a drag-and-drop scheme for example. But explicit opting
in at least gives people a way to deal with it (especially
if they can opt back out, of course.)
Logged In: YES
user_id=21627
I originally requested "image autocollect <name> on/off".
Would that API resolve your concerns?
Logged In: YES
user_id=79902
That'd satisfy the general capability at a semantic level.
I'm not sure I'm happy with it syntactically though. I'll
need think about this further...
Logged In: YES
user_id=971615
I don't personally need this, however I was reading all the
messages here. What I would suggest is that there should be
an option on an image (that you can set when you create it,
or change later) that says whether the image should
automatically be deleted when there is no reference to it.
This could then be implemented by every time a reference to
an image is removed it first checks if it is the last
reference to this image and then if the option is set to
delete once it is not referenced (or vice versa).
That is my 2c :).
Lio.
Logged In: YES
user_id=971615
Just another quick comment:
It would be very easy to create a function that does the
original request of deleting unused images when you call the
function.
It could be implemented with:
foreach im [image names] {
if { ![image inuse $im] } {
image delete $im
}
Lio.
Logged In: YES
user_id=79902
The problem is "what constitutes not being in use?"
Suppose I have a list of images that some kind of recurring
[after] callback is making a label cycle around. Are (most
of) those not in use?
There are too many nasty cases like that for me to feel that
the cheap-hack approach is generally applicable. And for
those cases where it can be used, it's easy to do that at
the script level; no core intervention is required.
Logged In: YES
user_id=971615
The point about the script was saying that core intervention
is not required as if the user wants (needs) the function
that he was asking for he can very easily write it himself.
Actually he doesn't even need to write it himself as I have
pretty much given all the code required to implement it as a
script.
Lio.
Logged In: YES
user_id=79902
Sure, but there's a separate notion of image lifespan that
is probably what the original proposer wanted, namely that
of the "object reference". It is *almost* possible to make
that work in Tcl/Tk as it currently stands (i.e. you can
make it work properly in many applications) but there are
outstanding issues in this area that are very well known to
the TCT.
Fixing those problems (which would make this FRQ easy to
satisfy) is non-trivial, since the most obvious things lead
to over-eager image disposal (the converse of the current
problem where it is easy to leak images...)
I don't want to go into detail here, since it is out of
scope for Tk (and probably properly the subject of a paper
or two in a Tcl conference...)