Cedric wrote: > 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.
raster will be the one to bless or damn this :) but I took a quick look at it and thought I'd give you some of my impressions. I like the cache stuff. I actually had to do something similar recently (though I didn't bother abstracting it as much as you did here). A couple of things quickly came to mind though: You're using the image struct's "extended_info" pointer, in the sdl engine, to hold an engine-specific surface (namely, an sdl surface), I added an extra "void *engine_surface" for this (I did it for the xrender and gl engines), since the 'extended_info' pointer was likely intended to hold 'meta data' that an image file format may have..? There are some things I think could be cleaned up... maybe the various "assert" calls could be replaced by a more 'silent' means of checking for invalid inputs? Also, why the need to keep a hash of 'inactive' images when there's the (last used precedence) list of such? > - 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. Ummm... I'll have to preface what follows here by saying that I know nothing about sdl, and haven't really looked at the engine too much... But from what I can gather: It seems to be what I'd call a 'generic' implementation -- ie. uses the software routines for things and puts the result argb on the dst surface. If so, I think it might then be best to call it "software_sdl"? Also, if so, why do you seem to keep an sdl surface for src images, when it doesn't seem to be used for any copying or compositing to a dst surface? (for the yuv color space why not then use software conversion routines?) Or maybe I'm reading that wrong? I did visit the sdl website, and there seems to be mention of using "OpenGL with SDL"... Is it possible to maybe also have a "gl_sdl" version of the engine.. ie. one which would presumably use some gl rendering? > Now, this is not perfect and I think some more work is needed. It's a lot, even as is :) Sure it could be better... What can't? Anyway.... that's just my limited feedback for now, based on a quick look. I'm sure raster will disect and digest it all far better, when he gets a chance. :) Keep the spam coming. jose. BTW: You never did tell me 'what is sdl' or 'why is it interesting' from your own point of view :) -- not the sdl website's views!. ------------------------------------------------------------------------- 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