On Sun, 2 Dec 2007 09:16:30 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > As raster mentioned, and as I believe, the best thing for epsilon > > > would be a rewrite using evas instead of imlib2... something > > > extremely similar to e_thumb. Raster said that if this did occur, > > > e would likely change to using epsilon as well. > > If epsilon is still using imlib2 for creating thumbs, it must > be either because at the time it first appeared evas could not then > save images to files, or maybe because it wanted to use more image correct. evas was unable to save images at the time. it can now. has been able to for a while. > loaders/savers than evas had (evas had built-in jpg/png/eet only at > first, or rather at second - at first it also used imlib2 for loading, > and the original-original evas used imlib2 for drawing too). yup. evas still has fewer loaders, but i like it this way for now as it lets us more easily changing things. we can expand this over time as needed, but it does cover a lot of the most common formats. > If so, these two issues should no longer be relevant: evas correct :) > can save to files, and one can write as many loaders/savers as desired. > In fact, I think that imlib2 doesn't have an svg loader, which evas > does. Any special-purpose loaders that one may want for epsilon, but > not in current evas, one could write expressly for epsilon if desired. or for evas - and add more loaders in. steal them from imlib2. port them over. not hard really. same pixel format (argb32). > On the other hand, uing evas for simply loading and saving > 'thumbnails' of a couple of images is somewhat of an overkill.. but > not if you're doing many. true - but since epsilon already uses it - it's a moot point really. imlib2 is less and less useful - evas has taken over most of what imlib2 could do (and a lot more besides). for generating thumbnails evas has all u need. > > - how expensive is evas/ecore_evas_buffer in comparison to imlib2 > > to generate thumbs; > > You don't need ecore_evas_buffer to generate 'thumbs' of > jpg/png/svg, that's only for generating smaller views of a 'general' > evas canvas rendering. For example, if you want to show a live thumb > of an animated edje, or bunch of edjes, or just about anything. well you will want a buffer - for the scaling. u load image int an evas image object in a buffer canvas. this buffer canvas lives in the image object of another buffer canvas (parent). you simply create, show (move, resize, set properties) on the image object u loaded, force an evas_render() on the buffer evas that holds this image object. this means the parent image object in the parent buffer canvas will now have pixels that are valid and rescaled down. now just save this image object in the parent buffer (u don't need to render the parent buffer canvas which means its just a wrapping data structure to give you and image object to be able to call save() on). it shouldn't be any significant overhead (almost none when compared to the expense of loading the image file from disk, decoding, scaling it and then saving it). > > - saving to eet the uncompressed data really help? Ok, this is > > more about testing on our hardware, but maybe it will not help > > and it's cheaper to uncompress a JPEG than read pixels from flash > > (flash slowness versus cpu usage). In that case, what's the best > > option to save the image as JPEG? Create an evas_object_image on > > the same canvas, set it's pixesl to buffer pixels and then > > evas_object_image_save() it? yup. compression in the end is a disk (or flash) IO tradeoff vs CPU. in the end you will find its faster to compress it as the extra "Disk" space used is huge when you don't compress, and you pay a big price in IO overhead if not compressed. jpeg tends to decompress VERY fast even compression is fast - much faster than png (going via libpng or libjpeg). > Saving what to eet? Thumbs of jpgs/pngs? Depends what you > want to do with them, and how many... The "best option to save > the image as JPEG" is somewhat hard to say - it depends on the > context you're working with. yup. eet does one thing u cant do with jpeg/png - it allows BOTH lossy compression (jpeg style) AND an alpha channel - so if you are thumbnailing something big - with an alpha channel, eet is the way to go for speed of saving the thumb, loading and disk usage for the thumb. > But if you're using evas, and you want to use it to load > and save 'thumbs' of jpgs back as jpgs, then just create an image > object (hide it), set the load size (evas uses the same 'quick' > thumbing mechanism for jpgs as epeg), set the file, and then save > it to the thumb file (use flags for jpg quality and compression), > repeating for as many image files as you want. Or if you want to > do this in a separate evas, then create a buffer evas and then do > as above. yup. in e17 e_thumb* does just that. use it/steal from it etc. this stuff should probably be rolled into epsilon replacing the imlib2 stuff. > > Also, what to change in e_thumb to make it the perfect "epsilon"? > > fdo-compatible saving? Use epeg? > > What is "fdo-compatible saving"? you must generate thumbs given a certain algorithm (md5 hash of the file, in ~/.thumbnails and it must be in png format - which i disagree with. if its a jpeg - why write a thumb as a png? slower. and uses more disk space by quite a margin. imho the standard should support jpeg as well). > A more general question would be: What does epsilon not > have right now that would make it better for people's needs? > Any capabilities it's missing that people want? Any api additions > or modifications anyone have in mind? probably removal of imlib2 - evas stuff replacing it as above. :) also u'd need to be able to tell it not just the enumerated thumb size, but an aspect ratio too - this is where edje complicates things. if you have a 1920x1080 screen - a good edje wallpaper can adjust to look right. textures will just tile, shading may scale, some logo will just stay a fixed size but centered etc. in 640x480 it will be different. the layout of the edje will change - thus a thumbnail of the same .edj needs to also know the target resolution (and thus aspect ratio) to generate a thumbnail that is accurate. also the problem of which edje element within the file (a .edj can contain multiple elements - and themes will do just that). epsilon has no way to pass this information in. > jose. > > _____________________________________________________________ > Discount Online Trading - Click Now! > http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8XfD6Y4cnWo37eHOLUtROMi38mJQe5Buj2XyWLbBt0ctS/ > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
