I am trying to help design an api for tile management in gegl. What I am concerned about is designing the api to be flexible enough to allow future changes to the swapping, caching and tiling code without placing limitations on how to best go about achieving this.

What I am going for here is a request for comments. I spout some ideas about how I think how tilemanagement would be done, and those people that actually have to deal with tile management tell me how I might improve things.

At the moment, I know very little about how gimp uses tiles (though a pretty good understanding of how it caches and swaps).

Here are the ideas I am starting with. Please tell me where I should be concerned that I am limiting a potentially useful feature of tiling, something you think should or should not be exposed about the tiling system, or any ideas about how the tiling system should work. I am hoping here to rely on the vast collective experience of the gimp developers, rather than trying to forsee everything myself.

Also, as of yet, there is not code to back up these ideas. I am just trying to make sure I am not being too short sighted before actually trying to make this work.

Here be my ideas:

There should and an Interface (the gobject kind) that defines the api of an object that is swapable (call it GeglSwapable) and a similar interface for things that are cacheable (GeglCacheable). I don't see why non-cacheable things should be swapable, so GeglCacheable should be a pre-requisite of a GeglSwapable.

An object that conforms to GeglCachable would know how to inform an inquisitive Cache implementation of potential future requested elements. How to attach itself to a particular cache manager, and how to check that it's data is avaiable in the cache before trying to get it from some real source.

An object that conforms to GeglSwapable should know how to flatten and free it's swapable data when asked to, and how to unflatten and restore whatever state it handed off.

A GeglTile would be a continuous allocation of memory that represented some portion of a two-dimensional area of data. A GeglTile would be an abstraction below a Channel. Channels should behave (behind a hopfully well designed api) as a continuous block of 2 dimensional scalar values. This demands that Channels have iterators that allow one to advance by scanlines in either direction (x or y) and to pull element by element, values from anywhere in the Channel, as though the entire channel exsisted in memory. GeglTiles (or some parent object) would also be the thing that implements GeglSwapable and GeglCacheable.

A CacheManager would need to know how to fetch things from the cache, put new things in the cache, expire old things from the cache, and request that the swap manager swap out stuff.

A SwapManager would need to know how to fetch from disk, keep track of unused chunks of disk space, and restore things from the disk.

Here is a summary of the demands of the api that I of expounded on above:



gpointer data
GeglTile* left
GeglTile* right
GeglTile* up
GeglTile* down
GeglTile* top_left
GeglTile* top_right
GeglTile* bottom_left
GeglTile* bottom_right

GeglTile *top_left


Now that I have stated such a mouthful, I am getting other ideas that might be appropriate. It may be more meaningful to Let GeglCacheManger really manage a stack of caches, which would cause an expiration from a higher cache to push the data to a lower cache. Then let GeglSwap and GeglMemCache take over and place GeglMemCache on top of GeglSwap (both of which would inherit a common interface). This would even allow special purpose cache architectures to be place above more general (and thus sometimes (always?) slower) architechtues.

How well do these ideas fit the needs of the gimp programmers?

Daniel S. Rogers

Gimp-developer mailing list

Reply via email to