On Friday 06 April 2007 09:58:26 [EMAIL PROTECTED] wrote:
> Cedric wrote:
> > - 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.
Nice you take the time also.
> 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..?
I didn't see it, it would perhaps be a good idea to have this engine_surface
directly as a part of the RGBA_Image (I did use extended_info, because I
didn't see any use of it).
> 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?
I like assert when developping, they stop the apps as soon as needed. But
after debugging, they must be useless and never trigerred. I could remove
them completely I think.
> Also, why the need to keep a hash of 'inactive' images
> when there's the (last used precedence) list of such?
It's faster, easier (one line of code :-) ), to look into a hash to
find the
right image to use. The LRU is only used when we need to drop some content
due to cache presure.
> > - 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"?
Yes, it's mainly a software_sdl. I wanted to use more SDL function, but most
of them are useless due to the strange way they handle the alpha case. The
only case that really use SDL is when doing the update of a surface with
SDL_UpdateRects.
> 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?
Mainly for SDL_UpdateRects as it could be of some use, and also because direct
access to the SDL_Surface is the same as an access to the RGBA_Surface
software surface.
> (for the yuv color space why not then use software conversion routines?) Or
> maybe I'm reading that wrong?
I think I could use the software conversion routines, I just want to be sure
that the SDL YUV function are also useless before doing it.
> 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?
I did think about that also, but I must have some priority. So first I want to
have an Ecore with all others EFL running cleany with the software_sdl. So
it's definitively possible in my opinion, but not really on top of my TODO
list :)
> > 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. :)
Thanks, for the feedback !
> Keep the spam coming.
Of course !
> 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!.
Well for some crazy idea. I did notice that many little 2D game on Linux are
using SDL, but they always need to re develop their own EFL like
functionnality because SDL is really limited.
The drawback of the EFL is that they need a specific engine each time
we want
to make it run on a new device/OS. The SDL provide an easy solution to this
problem (not the fastest engine, but must work).
But don't think that having a SDL engine will give us a portable
solution. A
lot more work will be needed for that. It's just a first step. I also
understand that the EFL are much more complex than the SDL and people could
be afraid of that.
Right now I am playing with the EFL, and that's fun... perhaps more
than
playing games ;)
Cedric
-------------------------------------------------------------------------
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
