>> 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. :)
>>
>>
>>
> And just to quadruple-state my reasons for proposing this:
>
> I would *prefer* to have (closer to the current version),
>
> evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos);
> evas_object_gradient_alpha_stop_insert(grad, a, float pos);
>
> where the rgba in the color-stop one are assumed premul, and I would also
> keep the 'data' ones,
>
> evas_object_gradient_color_data_set(grad, *data, len, has_alpha);
> evas_object_gradient_alpha_data_set(grad, *data, len);
>
> They're far more flexible and consistent with a premul compositing
> model..
>
> BUT, the problem with these is that there's NO way to directly implement
> them (in general) with things like xrender, or cairo, or OpenVG, .... We'd
> have
> to do things in software most of the time and create implementation
> complications
> in general to get some direct support.
>
> It was a good experiment, and there are people who would like to see
> this
> kind of thing, but it's likely never going to happen with any of the
> "standards"
> or with most libs/apis one could use for engine backends.. :( Hence, better
> to
> conform, as this aspect is important.
>
> Of course this is as far as the premul vs non-premul stops deal. The
> other
> part of changing to inserting with a "float pos" rather than adding stops with
> some int delta/distance/whatnot.. is partly in order to also have more direct
> 'standard' support, but also to make it somewhat more intuitive.
>
There is one other option here -- namely to accomodate *both* kinds of
color-stops, premul and non-premul (with no mixing of the two - doing so would
clear the gradient of the former different set of stops or data), so that one
can keep both ways. If an engine backend supports only non-premul stops,
then those are done directly, and one reverts to software for the premul ones.
So, as a more 'positive' alternative, one may consider:
// premul color-stops api,
evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos);
evas_object_gradient_alpha_stop_insert(grad, a, float pos);
and also the 'data' ones (the color data premul of course)
evas_object_gradient_color_data_set(grad, *data, len, has_alpha);
evas_object_gradient_alpha_data_set(grad, *data, len);
and also,
// non-premul color-stops api,
evas_object_gradient_color_np_stop_insert(grad, r, r, b, a, float pos);
where of course the 'np' stands for non-premul r,g,b,a.
____________________________________________________________
Hotel pics, info and virtual tours. Click here to book a hotel online.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmLRYlJnF5QRabaPWTj3m9UzpmwX10g1vyCHFScPiHEBcc/
-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
