> > > No it won't work to use his caching code, as is, for some
> > > of the other engines. But it can be made to work. One needs to
> > > ....
> > > ....
> > >
> > Just to follow up on this a bit..
> >
> > Again, one could make it work (though it would require a bit
> > of work, some re-structuring of current stuff, etc), but the real
> > question here is wether this would be desirable to have or not.
> > One thing this would allow is for 'localized' image caches,
> > eg. it would allow per-evas canvas caches if desired (and indeed
> > his current sdl engine implementation has that), or per-'engine'
> > (which is better, as far as memory use is concerned), etc.
> > It would also 'simplify' the caching code a bit as it would
> > have a generalized form, and indeed it also depends on a
> > generalized image structure.
> >
> > However, in the interest of expediting a "software_sdl"
> > engine, I'd suggest that maybe it would be better if that part
> > of it were left for another time, when such an idea can be looked
> > at in more detail. :)
>
> agreed. a generic caching mechanism beyond the basic one behind
> the common argb32 code needs more discussion. as i have mentioned
> i see the need to make a layer better than just the caches so far
> discussed. tile-based caches, tile-based retrieval and storage of
> data so we can cache pre-scaled data, even dynamically page image
> data from files "as needed" if you have massive images for example
> etc.
Yeah, you've mentioned this to me before.. It's a good idea,
but it would take things quite a bit further than what's needed
right now. We've also talked about a 'generic' cache mechanism
before.. one that could be useful as an ecore lib say (and recall
that such a mechanism required one to give 'free', 'copy', and
other functions - very similar to what cedric proposed). But again,
that is going further afield than is needed right now.
As far as evas image caching goes, one doesn't really need
a mechanism exactly like what cedric had, but some work there would
be good for several reasons.
First, and I think this is initially what prompted him to
attempt to rewrite things, it would be useful to have things more
'generic' in form - in order to reduce code duplication, to make
it easier to deal with engine specific image caching issues, and
things of that sort.
For me though, this is intertwined with another basic aspect
that's needed in order to extend evas' current capabilities - namely,
we need a kind of 'engine level' object system.. preferably, one
that allows for easily 'falling back' on software routines if needed.
Now, there are many ways one could do that, eg. one could
use something like what you have in e17, or in ewl or etk...
For me it was simpler to use a version of the current canvas-level
object design.
When it comes to image objects though, we also need a generic
image structure to hold data and whatever engie specific stuff.. and
to make things easier let's say we want to build these on-top-of
the current RGBA_Image structure.
Let's call these structures Engine_Image, and let's take
it to be of a form like:
struct Engine_Image
{
RGBA_Image *im;
void *engine_data;
char *cache_key;
int flags;
int refs;
};
Here, the "void *engine_data" holds any engine specific
stuff, eg. for the xrender based engines this would be similar to
the current XRImage structure (minus certain things).
Ok, these are our engine images which are to be loaded/
cached/etc. How do we rewrite the current caching mechnism around
these?
First, one needs a "cache" for each engine. This structure
can be whatever, but let's take it like the current active/inactive/
dirty system (I'm not sure the 'dirty' hash is really worth having),
which will cache such engine_image pointers. The loading/caching
of these will use a key depending not only on the (file,key,lopts)
combo, but also on engine specific data.
Then one needs a global "common" hash of RGBA_Image pointers
which will cache all images loaded with only the (file,key,lopts).
The 'trick' then is simply how to connect an engine image's
ref count (in the engine's cache) with the ref count of the corresp
RGBA_Image in the common hash. This can be done in many ways, but
the simplest is to just take the ref count of an image in the
global, common hash to be the sum of the ref counts of all cached
engine images (active or inactive, in all engines) which use the
corresponding RGBA_Image.
For example, if an engine wants to 'get' an image, given
some input (f,k,lo,eng_data), it would generate the cache_key as it
sees fit and look for the image in the 'cache' (active/inactive),
and if successful it would ref up not only the engine image but
also the rgba image it holds. If not, then it needs to create a new
engine image and see if it can get an rgba image, via (f,k,lo),
from the common hash, or load a new one via the common loaders.
In any case, this would be one way - as far as basic image
caching goes. More complex caching stuff, as you mention you'd like,
is something more involved and possibly more flexible in how it
could be realized.
jose.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
