On Wed, 25 Apr 2007 04:19:06 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> > > > 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.
actually now you mention it - i think we really do need a much better generic
SHARED caching lib. i have mulled over this before, but we need a way for
multiple PROCESSES to share a cache - in ram. i.e. shm segments (or mmap shared
files). so you'd need either a cache handler daemon that everyone ipc's to or a
way of having a meritocracy with the cache - but you need to lock, unlock,
modify, dirty etc. to date i actually know of no such implementation of such a
system anywhere for linux/unix etc. - a userspace generic "higher level data"
cache.
> 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.
sure. agreed. evas's internals probably need a bit of a going-over.
> 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.
indeed. it has some of that for now - but not all of it.
> 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).
actually - this is a problem. you need to be able to have MULTIPLE engine share
the same cached image - you need multiple engine_data's - thus why i wrapped
the other way around. you need to support a software_x11, xrender_x11, gl_x11
et. engine all at once (currently this is broken for fonts actually as they
work in this way above).
> 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.
or ever ref of an engine object refs its src and unrefs again - thus havign the
effect above.
> 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.
if we are going to revisit caching significantly - i'd really like to look at a
shared cache - ewl and etk would love it as right now each process needs to
load its own fonts, images etc. and so N processes loading the same data do it
N times.
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
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
