> > But the 'problem' goes deeper than that. Right now the
> > argb data itself (ie. the result of loading things given only
> > the file/key/load_opts combo) may be shared by several cached
> > engine images, ie. images which have the same file/key/load_opts
> > but could have different 'displays' say, and this is the real
> > source of the 'problem'.
>
> I am not sure if I understand correctly the problem. As I currently
> implemented my cache mecanism, a RGBA_Image could only end in one
> image cache linked with one engine and one cache_key. Now what we
> want, is having one RGBA_Image in multiple cache linked with multiple
> engine, but with one cache_key. This cache_key should only be the
> same if all engine are really ok to share this RGBA_Image. Is it
> correct ?
> In that case, I need to provide a way to request each engine
> to compute the cache_key and if they all give the same answer,
> it's ok (I take for granted the fact that I could have multiple
> cache for one RGBA_Image. I know, it will need some thinking also).
> Or did I miss a bigger problem ?
Errrr... I think if I try and explain this again I'm likely
to cause more confusion. :)
Take a quick look at eg. the xrender-x11 and gl image
cache related stuff. Every engine 'image' needs to keep at least
argb32 data that one can load/set/get from the canvas api. It also
may want to keep such data in engine specific buffers of some sort
(if it can composite such to the dst target surface via some means
it posseses -- in your sdl engine case, you're not using any sdl
provided functions for compositing, so you can't really benefit
from keeping loaded data in sdl surfaces). But these engine specific
buffers may require some form of differentiation, apart from the
argb32 data they are made to hold.
Now, for 'loading', one wants to be able to keep as few
copies of the argb32 data as possible - regardless of the number of
canvases, the type of engines, the means the engines are using for
holding the data, etc.
So, what are you going to do if you want to load file "blah"
ONLY ONCE, but maybe use its argb32 data in many canvases, which
may be using many different engines, some of which may want to hold
that data in 'surfaces', which may need to be created in some
particular way, dependent on engine info (even though they take the
same loaded argb32 data as input - no making copies of the loaded
data allowed either). ???
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
