Carsten wrote:
> 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?
>
>
Object relative, ie. rel to obj's coord sys. - that works best for
evas' semantics of move,
resize of objs, and makes it easier to use as a retained-mode canvas.
If the grad obj becomes 'bound' as a fill or stroke texture obj of
another (vgfx) obj, then the
fill geometry is taken rel to the textured obj coords.
>> (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 ?
>
In part, to allow for odd sized fills.. make it fit an odd sized
rect for example.
>
>> (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.
>
Exactly. The 'downside' is that it breaks current evas api. But
better now while still
pre-alpha. Or, if it's decided best for it to be released first, then it
would have to wait
for a subsequent api-breaking new version.
____________________________________________________________
Stuck in a dead end job?? Click to start living your dreams by earning an
online degree.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNfaFhX1YFaVpk6mcbJdi6FBJ29Hu8rvK0E2qiyPErEtI6Y/
-------------------------------------------------------------------------
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
