On Tue, Jun 24, 2008 at 2:28 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > > Not at all. This could be made to fit in well with evas too, though > it doesn't have to be (and evas could do its own sync loading if desired > as well). Eventually, there could be many benefits from this, even apart > from app/lib shared resources, eg. network file access (including the net). >
Just in time too - Cedric, Jorge, and I were discussing Evoak again, this could be a step in the right direction. > And btw, Cedric: there's no need that 'image load' tests/calls should > be involved in the image render func, this would actually be best done in an > image render-pre func - an engine level such func that is. Of course the > whole of evas image internals need a large re-doing.. Every canvas level > image obj instance needs to have a corresponding engine level one, which > will hold such instance data as borders, fill size, transform, etc. It will > have a pointer to the shared (or not) image src, but one needs such engine > level image objs (and appropriate set of new engine funcs) or there's no way > to do much more with images. > > -- Hisham Mardam Bey http://hisham.cc/ +1-514-966-8359 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
