Re: SetPixelCacheMethods() vs. SyncPixelCache() vs. SyncCacheNexus() vs. SyncCacheView()

Bob -

my point was that since the nexus cache functions are officially exported 
(e.g. GetCacheNexus()), the higher functions that use the function pointers 
are meaningless.
If I would use the function pointer extensions mechanism, codes that call 
GetCacheNexus() would crash.
The architecture is just not very clean in this area.
I think I will assume that cache_view.c, and all function pointer codes are 
"dead-end", and instead I will use and extend the nexus functions directly.

Many thanks for your answer,
Wolfgang

On Wednesday 07 January 2004 02:29, Bob Friesenhahn wrote:
> On Tue, 6 Jan 2004, Wolfgang Spraul wrote:
> > I noticed some architectural overlap in cache.c/cache_view.c and wasn't
> > sure which functions (if any) are "older" vs. "newer", or "preferred" or
> > whatever. Basically, cache.c:GetCacheInfo() will initialize a set of
> > cache function pointers with SetPixelCacheMethods() to point to
> > SyncPixelCache() (for example). SyncPixelCache() will then in turn call
> > SyncCacheNexus(). Then, there are the "cache view" functions in
> > cache_view.c, which generally seem to be small wrappers that call the
> > "nexus" cache functions family. The website doc seems to mention only the
> > cache view functions.
> > All of those functions are flagged as MagickExport, i.e. meant to be
> > called from outside.
>
> Cache.c was written by John Cristy.  While it is true that we
> successfully added a few GraphicsMagick enhancements to cache.c, for
> any of us to properly understand how to extend it it, we have to study
> the code just as you are doing.  It is not exactly light reading.
> That means that none of us will be able to answer these detailed
> questions without spending a day looking at the code ourselves.
> Perhaps John Cristy would be willing to answer some of your questions.
>
> We do eventually plan to extend the pixel cache design to support
> compact grayscale, and (perhaps) bilevel pixel storage without
> breaking the existing PixelPacket/Indexes API.
>
> > Let's say I want to add another cache type (in addition to DiskCache,
> > MemoryCache, MapCache). How should I do this? Should I add it to the
> > existing functions in cache.c as new cases, or add new functions and use
> > the function pointer setup mechanism?
>
> I doubt that anyone in the world has used the function pointer setup
> mechanism since the implementation has been used to satisify the needs
> of cache.c.  If you need your code to be somewhat independent, then it
> is worth giving it a try, otherwise using the existing patterns in
> cache.c and adding code to cache.c may be easiest.
>
> Bob
> ======================================
> Bob Friesenhahn
> [email protected]
> http://www.simplesystems.org/users/bfriesen
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Graphicsmagick-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html