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
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer