Thu 15 May 2008 08:25:20 AM UTC, comment #2:
Some basic preliminary design notes:
-Every image should have a 'reference count' (type unsigned int), and a 'permanence' flag (type char).
-The reference count is used (obviously) to keep track of the amount of references made to an image. The tricky part is keeping this count correct at all times. This means that, for the lifetime of a tile, mob or other image-referencing item (a window, for instance), a reference should be kept. This reference should be destroyed afterwards. If the amount of references ever reaches 0 (on destruction of a reference), the image is destroyed (while keeping the indices of all other images in the sequence constant), unless the permanence of the image is non-zero.
-The above causes issues with things kept outside of sequences, for example tiles kept outside of tilegrids. Stale images could be kept indefinitely if tiles are not properly 'destroyed'. However, this is better than images growing stale while in use (It at least does not cause crashes).
-All users should see of this GC-ing strategy is A: that it works silently in the background (it is the duty of the API to properly handle references) and B: that they have control over the permanence flag of images.
-This latter flag exists because of use cases like the below:
A user has a tilegrid, containing a number of blue tiles, image index 0. A single tile of this grid, chosen randomly, is replaced by a red tile, image index 1. In doing so, the user re-replaces the old red tile by a blue tile.
If there is no image permanence, the image is destroyed upon destruction of the old red tile, and reallocated upon creation of the new red tile.
|