Re: [E-devel] Epsilon problems

[Carsten H. (T. R. <ra...@ra...>]

On Tue, 4 Dec 2007 07:36:56 GMT "jos...@ju..." <jos...@ju...> babbled:

> 
> > >       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.

yup. scaling is "correct" with premul if you have an alpha channel - without it
it's not.

> 	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.

yup.

> > > 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. :)

imho - no need for this. using a single slave process u feed a series of image
to thumbnail to - then it replies when its done with each would allow you to in
fact only set the image file on the thumb object if you want. u'd save
allocating the image object and evas data structs. as such the buffer canvas
for the parent evas can be 1x1 pixel. its size is irrelevant. see
e_thumb_main.c the cost of thise creation and object managing is really tiny -
almost nothing, compared to the cost of image load, scale and save.


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...