Carsten wrote:
> ....... what your cache doesn't handle is if you have 2 or 3
> or 4 different engines when 2 of them are NOT software engines
> and both want DIFFERENT "private" engine data (a pixmap, render
> picture, texture etc.). they share the RGBA_Image but they are
> not able to share the private engine data for the image - you need
> to keep both bits of private enigne data - that is what each
> engine's wrapping basically does. secondly for some engines
> there may need to be MULTIPLE private copies - different visuals,
> colormaps etc. for example. different screens etc. this here is
> actually a current bug in the RGBA_Font stuff - the way i did the
> engine specific glyph painting callbacks means only 1 engine can
> place private data there. i need to fix this - but it would be
> bad to let the same issue creep in for something bigger like
> images :)
> 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.
Yeah. Except that the 'sharing' of the image cache across
engines of different 'types', while desirable from certain points
of view (and it's initially the way I thought things should work),
is now becoming a source of complexity and 'issues' for me with
other things.
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
