Cedric wrote:
> > this is why there is a specific engine copy wrapping the image
> > - the RGBA_Image just acts as a source of RGBA pixel data.
> > the wrapping engine image colds a pointer to that plus engine
> > specific data. the image is also looked up not just by filename
> > + key, but ALSO by engine specific properties too.
>
> When I did take a look at others engines, I missed such idea.
> So I didn't take them into account for the cache. I will need
> to think how I could solve that, but I would like to try to solve
> this on a real case. Do you have an engine that need more than
> one private data ? (One that could be a good start to see,
> understand and fix this problem)
The xrender based engines. The loaded data is kept in
'pictures', which are resources that depend on other X stuff.
That part would be easy to fix in what you have: add a
function prototype to generate the 'cache_key' from given input
(file, key, load_opts, void *engine_data).
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'.
jose.
-------------------------------------------------------------------------
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
