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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
