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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel