On Mon, 9 Apr 2007 07:47:11 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > ok- started reviewing... and i'll basically cover as much as > > > i had time to review here. > > > > > > 1. shared evas image cache - good idea, BUT... has problems. > > > ... > > > ... > > > ... > > > > 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. > Cedric: It seems to me that you don't really this for your > engine - you don't really need to use an sdl surface for images > that are created via the canvas api.. the only time I see that > you really need to hold an sdl surface in images (say in the > 'extended_info' pointer as you're now doing), is for images which > are obtained from the target (display) surface, and such images > don't need to use any cache aspects at all. If this is true, then > you can just use the current 'generic' image cache - like the other > software based engines do. > > Of course I could be wrong about this, it just seems that > way to me from looking at the engine a bit. :) > > 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 > -- ------------- 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
