> > 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).
Oh there's no "void *engine_surface" pointer right now, it's
something I added to my local copy since I wanted a single 'image'
structure for all engines (in fact, I had to introduce engine level
'objects' in order to have things like texturing and clipping).
The 'extended_info' pointer isn't used anywhere at the moment, but
it could be.. if indeed it was meant to hold additional file format
related 'meta data' of some sort.
> > 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.
Yes, but it's only faster when it *fails* to find a cached
(ie. inactive) image. If it suceeds (which is the whole point of
having the cache), then it could actually be slower.. because not
only will you have to remove the image from the inactive hash,
but also from the lru list and remove it. You also need to add
images to both the hash and the list when they are to be cached,
and when flushing the cache you again need to go thru both.
> > 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.
I'm not sure I follow you here.. Why do you need to keep
an sdl surface for api created images (eg. loaded, etc), when those
surfaces never seem to be used by any sdl functions (as far as a dst
sdl surface is concerned)?
There are cases where it could be useful to keep such,
even if you're not using any sdl based compositing funcs (assuming
there are such) -- you could use 'copy' ones in certain cases.
Using sdl copy funcs would also be useful in things like rect
drawing, with eg. rgb colors.
One thing you may want to look into, assuming sdl does have
some built-in compositing capabilities, is wether they can allow
for using premul color data (there's plenty of time to get into
that kind of thing a bit later).
> > 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 :)
Ahhh, good. :) I just wondered if it could be done at all.
There's plenty of time to get to such an engine, and/or tweak the
software based one, etc. It's a lot just to get something working
in place. :)
> > 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 ............
Now that was informative, and interesting! Thanks. :)
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
