>> ....... >> >>> that. if we ALWAYS scaled to the EXACT SIZE requested - we would be forced >>> to >>> always do it in software (as part of the generic loader) AND we now need to >>> also add flags as to if you want raw speed (nearest sampling) or filtered >>> scaling too - so it adds to the api, and hides and optimisation path. as >>> such >>> very few people use this api anyway as it requires a fairly advanced >>> knowledge >>> that you can pre-scale or need to scale to a given size always. i kept it >>> simple and lefts the rest up to the user. >>> >>> >>> >> I'm sorry Carsten, but what you're claiming here as a better load-opts >> pipeline >> and semantics in order to give potential gains for some cases needs to be >> put to >> the test. And just as importantly, we need to make sure that common-use cases >> aren't being hurt as a consequence. It's a confusing, complex, >> user-unfriendly >> semantics for image-size-load-options and really needs major gains across the >> board to justify it. >> >> Give me some real common-use cases and we'll go thru them in detail, for >> the >> main engines and various image formats, and see whether gains or losses are >> coming from this size-load-opts pipeline. >> I'll start it off here with one common-use case: Given an evas e, we want >> to create a "thumbnail" image object in e, of size w1xh1, from a given image >> file which is a png of size w0xh0, where w1 < w0, h1 < h0 but are otherwise >> arbitrary. We'll look at it for the cases of e being software, xrender, and >> gl based. >> >> We can move to the case of a jpg source next (which has certain >> interesting >> possibilities that could be explored), after we go thru this case. >> >> >> > No chance yet to go thru this case in detail? No problem, I'll go over it > so > everyone can understand the process one needs to go thru for this rather > common > 'thumbnailing' case. > > For a png src file, setting image-size-load-opts has as its current > semantics that: > it does absolutely nothing. It is useless to even try. > > In order to obtain the desired "thumbnail" image object on the evas e > (regardless > of the engine for e) for png sources, one instead has to: > > 1. Create an image obj on e, set the image size to the desired scaled size > of w0xh0 > and get its data. > > 2. Then, you need to create a (tmp) software buffer evas of size w0xh0 and > set the > above data as its buffer. > > 3. Now, you need to add an image object to that buffer evas, load the png > to it, > set the obj size to the src image size of w1xh1, set the fill-size to > w0xh0, and > finally call a render on the buffer evas so the image obj will get drawn > onto > the data buffer at the scaled size of w0xh0. > > 4. Finally you now have your image obj on the initial evas e, with the > image data at > the scaled size w0xh0 that you wanted, and can get rid of the buffer > evas. Ready > for rendering the thumbnail or saving to another file as your need calls > for. > >
Oops, got my 0 and 1 indexes reversed here. > This is an absurd situation for such a common, useful case. It's > considerably more > inefficient than simply having size-load-opts being respected for pngs, > regardless of > how the scaling would be done upon load (as a secondary/alternative option, > one could > also consider 'save' size opts, for the case of saving to a thumbnail file). > > Nothing is gained with the current semantics here, regardless of engine.. > quite the > opposite in fact. I can give you typical losses here, not enormous but > noticeable... > and this is not a rare or uncommon use-case. In fact, it may well be *the* > most common > use-case. > > Now, I can go thru other use-cases in detail with you, and I can go thru > them for > jpg sources as well.. but I can tell you right now that in just about every > conceivable > case -- you will lose. > You will lose even in the kinds of use-cases you mentioned where you have > just the right > gl driver and you're jpg-scaling to an approximate size and then gl scaling > to some result. > You will lose then if you have to do any mip-mapping, and even if you don't > you will still > eventually lose over time on scaled re-draws (vs. a one-time scale and then > copy-renders). > > How much more do you want to go over this? > And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) ____________________________________________________________ Click for free info on online degrees and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nlXFfGumsyJmZcJWsxvUVgovMahMvFQwn927ROnq7XhIy0c/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
