On Mon, 3 Dec 2007 06:07:22 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
>
> 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).
actually it uses a buffer canvas polus a sub-buffer canvas as per my other mail
ee and ee_im in the code in _e_thum_generate() :) BUT it doesnt need to
double-render. it only renders as much as neededc - the parent buffer canvas
itself never is rendered to - it is just a container for the im object:
im = ecore_evas_object_image_new(ee);
ee_im = evas_object_data_get(im, "Ecore_Evas");
that creates the image object which *IS* a buffer canvas - gets the buffer
canvas evas handle and adds anythign into that it wants to scale.
> 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.
not sure we should do that - as above - its possible to do this with buffer
canvases and objects. it's much more flexible as i can ALSO put MULTIPLE
objects into the thumb then. i can add watermarks and more to them.
> > 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.. :)
jpeg does - BUT it will scale to one of the scale-down sizes. 1/2, 1/4 or 1/8th
dimensions in each axis. e_thumb makes direct use of that.
> > 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. :)
i did :) epeg ALSO did all the fine-tuning scaling (ie it would scale to the
nearest 1/1, 1/2, 1/4 or 1/8th jpeg size "for free" on load and THEN scale to
the exact size. evas doesnt do the last fine-tune scale. it leaves this to
"runtime" (not load time) as evas can do this already as part of its rendering
pipeline. you then can choose if you want smooth scale or not and anything else
u like scaling-wise.
> 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.
i echo that - your work on canola2 has been amazing. i played with it and its
reaaaaaaly nice. it's an amazing bit of work - and really shows what u can do
with efl when you play with it right.
> 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
>
--
------------- 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
