> > 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).
>
> Hum... that pre-mul conversion just went unoticed to me :-)
> BTW, how does it pre-unmul? It looks like the conversion looses
> bits that you can't get anymore if you're using no-premul (other
> softwares other than evas-based), but maybe I'm overlooking things
> (maybe to get the blend done you'd loose the bits anyway).
Premul vs. non-premul is a long story.. I'm not sure any of
us has enough years left of life to get into it here, much less when
you're pressed for time (we can take it up later if you wish). :)
Yes, there are 'issues' either way with this, eg. scaling
deosn't give the same results with premul vs non-premul, and many
other aspects here and there. But overall, premul is the way that
makes the most sense for what evas is doing and what it's working
with.
For jpgs you don't have to worry about it since we only
deal with rgb images then, hence there's no difference (and no premul
or un-premul takes place). It does matter for pngs with alpha though,
and then it's fastest to deal with pngs embedded in eet. But I think
the cost of disk access is likely a far greater factor than any
premul/un-premul operations anyway.
> > 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 don't get why I'd need these extra steps. I'll not use current
> Canola's Evas to generate the thumb because the thumb generator will
> run on another process. But from that process I plan to just create
> the ecore_evas_buffer at the right thumb size and load image there
> (img1) resize and show, then use a hidden img2 to set the pixels
> based of buffer pixels, just to be able to save... I guess this is
> almost what you mean in your fast case?
Yes, except that img2 will need to allocate its own pixels
no matter what you do - because evas doesn't really allow you to
set external data without it first allocating data the size of the
image you want (unless there've been changes I don't know about).
So, either you create the buffer evas at thumb size and also
create img2 at that same thumb size (thus allocating another set of
pixels) and either copy the buffer pixels to img2 pixels, or just
set the buffer's pixels as img2's pixels (which will cause evas to
free the pixels it first allocated for img2, since it will note that
the data being set is different from the one it had) -OR- you'd first
want to create img2, set its size to the thumb size, get its data,
and use that data as the buffer evas' pixels, then render img1. But
setting up the buffer evas this way is a bit more subtle.
Neither of these are the best way though, not for images.
A better way is to set img1's load options to have the image load
the file data at the thumb size, and then just save it - that's all.
Except of course that won't work for all image formats since it
hasn't been completely implemented.. :(
> About size option to save, yes, it would be awesome.
It's a good way for more efficient thumbing of things like
edjes, and also for being able to do custom drawing on image data
and have that saved directly. One other aspect I think evas could
use is the ability to really set external data on images, ie. have
the user set its own data+size+has_alpha, without evas allocating
extra stuff.
> One extra idea: maybe this thumbnailer could have the
> ecore_evas_buffer +2 image objects created on the master process
> and used by children processes? Maybe this help a bit since it would
> be just a copy on write, no calcs would have to be done... maybe
> just a minimal saving? Do you see any problems with that (some file
> descriptors that would be inherited and problems could show?)
Ummm... let's hold those thoughts til a bit later. :)
_____________________________________________________________
Discount Online Trading - Click Now!
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8YQ3OosBiDbR5MVC796wufwRiXLdgKAj9KCmhQcnNxU5y/
-------------------------------------------------------------------------
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
