----- "Jose Gonzalez" <[EMAIL PROTECTED]> ha scritto:

> Let me continue with this evas gradients overview and with my
> 'critique'
> of its current state (largely due both to me and to legacy and other
> constraints),
> and to continue proposing *api-breaking* changes.
>       Before doing so though, let me quickly point out something to
> Dave regarding
> his (really nice) work on adding grad support to edje-editor:  Be
> careful with the
> issue of premul vs non-premul color spaces. Edje deals with non-premul
> color stops
> for gradients, whereas evas deals with premul color stops and separate
> alpha stops.
> You can get the former via the latter easily, but not the other way
> around.
>       If you want to 'input' non-premul color stops, ie. (r,g,b,a, d)
> where the 'a'
> isn't restricted to satisfy a >= r,g,b, like edje does, then in order
> to emulate
> this in evas (currently), you must do:

Thanks, you are right, fixed now.
Dave

> 
> evas_object_gradient_color_stop_add(grad, r, g, b, 255, d);
> evas_object_gradient_alpha_stop_add(grad, a, d);
> 
> this is what edje does internally - it's NOT the same thing as:
> 
> evas_object_gradient_color_stop_add(grad, r, g, b, a, d);
> 
> in fact, this latter will give you some very unexpected results, in
> general, if the
> r,g,b,a are indeed non-premul. :)
> 
>       It's a shame that all gfx apis/specs that deal with gradients
> use only the
> legacy non-premul approach :(  But it doesn't appear that this is
> *ever* going to
> change with any of the "standards", or any libs that want to support
> such standards
> and little else...
>       Hence my suggestion that evas do likewise. It would be the
> simplest way to be
> able to have direct support for grads via most engine 'backends' that
> are around.
> 
> 
>       Again, though not completely to my personal liking (and
> contradicting my original
> version), I'd like to propose changing the evas gradient 'spectrum'
> api to be of the form:
> 
> evas_object_gradient_color_stop_insert(grad, r, g, b, a, float pos);
> 
> where the 'r,g,b,a' part of the color-stop is assumed NON-PREMUL.
> 
>       Unless there's overwhelming resistance to this, or raster
> actually shows me
> that software 3D stuff he has from back when, I will change evas grad
> spectra
> to this form.. and hurt anyone who tries to stop it from being
> committed. :)
> 
>       I'll also go over the other half of the evas grad api (ie.
> related to type of
> grad, fill geometries, spread modes, and such stuff) a bit later, but
> any comments
> on this part from developers, designers, grandmothers, ... would be
> welcomed.
> 
> 
> ____________________________________________________________
> Explore all of Europe's beauty! Click now for great vacation
> packages!
> http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nKHLljrNsrAODiA6pFsQs8I4BnXKWo8Vt4B1zhhjjD1aW96/
> 
> -------------------------------------------------------------------------
> 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

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

Reply via email to