I wrote:
> .......
>> 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.
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?
____________________________________________________________
Click to become a master chef, own a restaurant and make millions.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m4pCm8tfNPOnBHbvfzxNIobkiSWZBRBZQyracA6bgUtIYsg/
-------------------------------------------------------------------------
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
