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:
GeglCacheable
attach_to_cache_manager()
get_prioritized_list_of_predictions()
fetch_from_cache()
expire_from_cache()
add_to_cache()
add_to_cache_maybe()
GeglSwapable
flatten()
unflatten()
swap_out()
swap_in()
swap_maybe()
GeglTile
gpointer data
GeglTile* left
GeglTile* right
GeglTile* up
GeglTile* down
GeglTile* top_left
GeglTile* top_right
GeglTile* bottom_left
GeglTile* bottom_right
GeglChannel
GeglTile *top_left
get_x_scanline_iterator
get_y_scanline_iterator
get_pixel(x,y)
set_pixel(x,y)
GeglChannelIterator
next_x()
next_y()
current_x_position
current_y_position
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
