On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> As the subject states, let me make a (relatively) short summary of some
> proposed changes and additions to the evas gfx api -- and I'll deal with only
> gradients and a possible vgfx-objs api, leaving transforms (mostly) and
> filters for later.
>
> First, changes to the current gradient api. This would replace the
> current api with the following one:
>
>
> (1) For creating gradients:
> **********************
>
> Evas_Object *evas_object_gradient_[type]_add(e);
>
> where the types are: linear and radial (and possibly later also angular,
> rectangular, triangular, sinusoidal, ...)
fair enough.
>
> (2) For setting gradient geometries (of a given type):
> *************************************************
>
> void evas_object_gradient_[type]_fill_set(obj, [geometry desc]);
>
>
> Where the [geom desc] is:
>
> (a) for linear grads,
>
> void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
> Evas_Coord x1, Evas_Coord
> y1);
fair enough. are co-ords relative to object or canvas-global? i think we
possible needs to make this object-relative?
> (b) for radial grads,
>
> void evas_object_gradient_radial_fill_set(obj, Evas_Coord cx0, Evas_Coord
> cy0, float rx, float ry);
>
> And we'd leave any other types for later as desired.
why float? why not Evas_Coord ?
>
>
> (3) For setting the gradient geometry's "spread" (or repeat, or extend) mode:
> ************************************************************************
>
> void evas_object_gradient_fill_spread_set(obj, int tile_mode);
>
>
>
> (4) For modifying the gradient geometry via a transform:
> ***************************************************
>
> void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
>
> where an 'Evas_Transform' is defined as:
>
> struct Evas_Transform
> {
> float mxx, mxy, mxz;
> float myx, myy, myz;
> float mzx, mzy, mzz;
> };
>
> ie. a 3x3 tmatrix which can be used to define a projective
> transformation or an affine one by ignoring the mzx,mzy,mzz components. Only
> affine ones supported for grad geometries (though the obj itself may support
> proj ones).
>
>
>
> (5) For clearing/defining the gradient obj's "spectrum":
> ***************************************************
>
> void evas_object_gradient_clear(obj);
>
> ie. remove any stops or data or whatnot from the gradient.
>
>
> void evas_object_gradient_color_np_stop_insert(obj, r, g, b, a, float pos);
>
> ie. insert a NON_PREMUL color at the given pos (clamped to be in [0,1])
>
> And *possibly* also similar premul such, as exist currently:
>
> void evas_object_gradient_color_stop_insert(obj, r, g, b, a, float pos);
> void evas_object_gradient_alpha_stop_insert(obj, a, float pos);
>
> void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
> void evas_object_gradient_alpha_data_set(obj, *data, len);
>
>
> That's it for basic gradient support (one could add more types, and one
> could add some funcs to query/modify stops if desired).
>
> The reasons for proposing these changes?
>
> To allow for direct support of gradients with various possible engine
> backends (eg. xrender, cairo, OpenVG, ... others).
> To have an api which is 'fitted' to what most all vgfx specs/lib-apis
> support with gradients.
> To more easily enable and represent various uses of gradients (including
> vgfx related ones like "texturing" of geometric figures with them).
>
>
> This then leads to a proposed api for vgfx-objects in evas -- and
> recall, by "vgfx-objects", we mean objs that can be "filled and/or
> stroked" (eg. lines, rects, polys, paths, ... maybe text) with a color or a
> "texture" (aka a paint or a pattern).
>
> Which I'll leave for a 'part II' of this thread...
hmm - ok, but these are very much linked. and addressing of vgfx needs to also
address all the usual gradients used in vgfx (eg svg). :) but overall this
seems to make sense above.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
-------------------------------------------------------------------------
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
