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