Gustavo wrote:
> > > - 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.
>
> that's why I asked, without any testing I'd say it will be slower/
> overkill...
>
Depends. If you're already using evas, and want to load and
save image files to smaller sized (thumbs) versions, then using evas
rather than going thru imlib2 could be faster - certainly for jpegs.
Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded
non-premul argb data, and when saving back to png it un-premuls back,
so we have: png-file-in -> premul -> scale-down -> un-premul ->
png-file-out. Which is slower than what imlib2 would do. But, if you
save the png to an eet, then as raster wanted to go with the "premul
flow", he made it so the no un-premul takes place when saving pngs to
eet.. and likewise, no premul takes place when loading pngs encoded
in eet (like eg, in edj files).
What would be slower is if you went thru intermediate
buffer evases to do down-scaling, ie. one would then have:
load-thing-at-its-natural-size-to-buffer-evas1 -> resize-evas1-to-
thing-size -> draw-it-to-evas1 -> set-pixels-of-buffer-evas1-as-data
-of-image-obj-of-buffer-evas2 -> resize-evas2-to-whatever -> set-fill
-and-size-of-image-obj-to-size-of-evas2 -> draw-image-obj -> [write-
pixels-of-evas2-to-out-file-somehow] this last step either directly
or again via setting the resulting pixels of buffer evas2 to another
image obj that you'd have created when you 'resized' evas2, and then
saving the image obj.... It's somewhat convoluted.
I looked at "e_thumb_main" - it saves to eet files directly.
That's not really sufficient for giving flexible thumbnail-file
saving functionality for others to use - it's just too restrictive
(and not really as fast as it could be in some cases).
I think evas needs to add an image saving 'size' option, maybe
best done via the current "flags" for saving, so that you can save
an image that alreday exists at some size (for whatever reason), to
a file at whatever other size one wants.
> seems that JPEG loader does respect load_size, PNG doesn't, not sure
> about others.
Bummer. But it's very easy to finish this off, for anyone who
wants to give it a shot.. :)
> I'm newbie to this project, so maybe you can help me understand this:
> is epeg just a test and the functionality was integrated to Evas's
> JPEG loader? This would be amazing.
That was raster's great desire - to have the evas jpeg loader
do what epeg did, and so did he add that in. :)
As to your being a newbie to the project.. I think you've been
a tremendous inspiration to everyone here Gustavo, you and your friends
and collegues there at Canola. Really.
jose.
_____________________________________________________________
Study law at a school near you. Click for more info.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmXCSm0cvWIFZ0N1bFZGJDUQ6vQVhZYPYDKK05IzLH0Ji/
-------------------------------------------------------------------------
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
