On 02/01/04, Daniel Rogers wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi, time for a status update,
>
> I finished writing the tests for GeglMemoryCache, the first concrete
> cache implementation. This also means I have a pretty good idea that
> GeglMemoryCache works :-). This was the first non-obvious class I had
> to write.
Great. This looks like a good start.
Dont forget to always chain up in any dispose or finalize routines...
eg
static void
finalize(GObject *gobject)
{
blah ... blah
G_OBJECT_CLASS(parent_class)->finalize(gobject);
}
If you dont override the finalize or dispose of course
you dont have to, but if you do, you must remember to chain up,
else Glib with object debugging turned on (G_ENABLE_DEBUG and G_TYPE_DEBUG_OBJECTS
both defined) will crash in g_object_last_unref trying to dispose/finalize
that object.
Also when I run the tests with the above mentioned debugging
flags for Glib turned on, I get the following object memory leaks
in test_gegl_memory_cache_caching:
GLib-GObject-Message: stale GObjects: 9
GLib-GObject-Message: [0x80738a0] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x8077998] stale GeglMockCacheEntry ref_count=3
GLib-GObject-Message: [0x807aa68] stale GeglMockCacheEntry ref_count=2
GLib-GObject-Message: [0x8075928] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x80789f8] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x807d768] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x8076960] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x8079a30] stale GeglMockCacheEntry ref_count=1
GLib-GObject-Message: [0x80748f0] stale GeglMockCacheEntry ref_count=1
These just mean there are some additional unrefs either in the tests or
in the actual object code that need to be added. Look into that if
you can...
>Of the stuff I have left to write:
>
> I need to write tests for the gegl-buffer.c caching and locking stuff.
> Non of these features acutally get used unless a cache is attached to
> the buffer, and now I have a cache to attach to the buffer.
>
> I need to write and test:
> gegl-color-space.c
> gegl-color-space-imp.c
> gegl-image.[ch]
> gegl-swap-cache.[ch]
> gegl-tile.c,
> gegl-tile-iterator.c.
>
> Of the remaining, gegl-color-space-imp, gegl-color-space, and
> gegl-swap-cache are non-obvious, though gegl-swap-cache is easy since I
> have already implemented a cache. The rest is pretty easy.
>
> Also, I probably need to get more gegl-buffer subclasses (which are
> pretty trivial) and modify the apis of GeglBuffer, GeglSampleModel, and
> GeglColorModel to handle bulk transfers. (this was a oops on my part,
> bulk transfers should have been there from the begining).
>
> Ok. Finally, some thoughts on how this stuff will be used:
>
> GeglImage will be abstract. There will be two subclass of GeglImage at
> the begining. GeglCachedImage and GeglOpImage. GeglCachedImage, backed
> by a GeglCache will be equivilent to TileManager. Just a store of tiles.
>
> GeglOpImage will be backed by a GeglOp and will be the object returned
> by an op when something requests an image from an op. GeglOpImage will
> know nothing about a GeglCache. A GeglOp will be resonsible for
> maintaining and using GeglCaches to cache the results of its image
> processing operations.
>
> As far as gimp integration:
> If we are going to make an easy transition, then the simplest transition
> will be to make The TileManager -> GeglImage substitution. This will be
> nice because code written to deal with GeglImages will be able to deal
> with GeglCachedImages and GeglOpImages identically. This will make the
> transistion to Op based image processing easier.
>
> Does this sound good to everyone?
Yes. This sounds about right. Once we have the new GeglImage class we
have the ops start using it as the image data that gets passed.
Once we have colormodel, samplemodel, colorspace and then tile, we
should be able to start moving image data through the graph again.
Calvin
