Re: [E-devel] Proposed evas gfx api changes and additions - part I.

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <jos...@ju...> 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)    ra...@ra...