On Wed, 21 Mar 2007 16:58:15 +0100 Cedric BAIL <[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. it's no different to what engines do, but in reverse. engines just wrap images up in their own objects and use the common code's stuff.l you only inverted the logic - it doesn't buy anything really. 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. also you were changing evas_common_load_image_from_file() to use extension to choose module - several big problems. 1. it's case sensitive. file.JPG will not pick the right loader first off 2. also file.jpeg will also go the "slow route". 3. even worse for .edj files! it will never pick the fast-path. slight problem here is that the sdl engine depends on this patch and i'm seeing some issues with it :( > Hi everybody, > > I finally got a SDL Engine running and starting to look correct. I > did split it in 3 patch. > > - evas_cache_image.diff: Add a global cache for image mechanism. > I hope it could be shared with other engine and reduce their code > complexity. This cache works more like the one from FreeType, you request > image/operation from the cache, and the cache forwards it if needed to the > right callback function. This need to be carefully reviewed, even if it seems > correct. I also included in this patch a new > 'evas_common_load_image_module_from_file' function that just create the > RGBA_Image without any cache manipulation. I also updated > 'evas_common_load_image_from_file' function to use it. > > - evas_sdl_engine.diff: This patch really provides the SDL engine. > You must not expect other colorspace than EVAS_COLORSPACE_ARGB8888 to > work. I have no plan to fix this now as I think it will be easier to test > that with emotion. So I first need an Ecore_SDL to fix this. > It doesn't use evas_pipe (and never will) as it need to use SDL > thread to do that same task, and I am really not planing to do it soon. > > - evas_sdl_test.diff: Add an old style evas test for SDL engine. > Every test must work, if not please report bugs to me :) > > Now, this is not perfect and I think some more work is needed. > I noticed that a lot of engine inherit their function from software > generic engine, but as we don't have an Evas_Common_Render_Engine, some > functions needs to be duplicated in all engines. If we have a common > Render_Engine structure with Tilebuf, Tilebuf_Rect, cur_rect and a void* > extended_render_engine for specific render engine information, this would not > be necessary. If everybody agree, I will just work on that. > During the time I developed the cache mechanism for the SDL engine, I > looked in all engines to understand how they did this task. And some engine > are first class citizen with complete/complex cache mechanism, others are > really not that much lucky :) I would like to make them use evas_cache_image > progressively. > When all of them will use evas_cache_image, it should be possible to > make the cache part of the common render engine and remove more code from the > engine. So maintaining and writing good engine should be more easy. Well > that's my objective here, so if people have better idea or any opinion on > this I would really like to ear them (here or on irc, I am cedric on #e, > don't hesitate to highlight). > > Cedric > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
