On Thu, 31 Jul 2008 12:04:39 +0200 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:
> On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> > 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, ...)
> >
> >
> > (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);
> >
> > (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.
> >
> >
> >
> > (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).
> >
>
> Some time ago i had another idea that i've been implementing, some of
> you already know enesim and ekeko, some other dont, let me explain why
> i think adding this to evas is not good imho.
>
> One of the main reasons of not releasing software is that it evolves
> too fast or it doesnt stabilize enough to make a stamp on a specific
> version and release it; but that is a direct consequence on what your
> lib wants to achieve. So im partisan of doing small things with solid
> API, of course not too small that it will make the lib itself dumb,
> but keep the objectives clear.
>
> Adding all of this to evas itself not only will make evas more bloated
> but more unmaintainable and of course the release time will be
> delayed, i'd like to share another idea that might help us achieve the
> same goals jose is trying to do, but keeping the api itself of evas
> clear enough.
>
> We are always on the objects/engines problem, how to support more
> objects features and how to add more engines and the truth is that the
> model we have right now doesnt scale too god, we are duplicating code
> here and there for engines and we are limited with current objects for
> fast drawing operations and smart objects for outsiders drawers whcih
> might not be as fast as an insider object.
>
> The idea is to flip the concept, totally. Not make the fast objects as
> inside objects and the engines as modules, but do both as modules with
> a different approach, mainly object+engine approach. The idea can be
> that an object (being a module or a library) register with evas for an
> specific object name and engine name (of course both the module and
> evas should share those names) like:
>
> evas_object_register(const char *name, const char *engine, Evas_Obj_Func);
>
> where the functions struct is something we already have but specific
> for that engine type. For this to happen, evas should export the
> needed functions and abstract the common code into exportable
> functions too.
>
> Use cases:
> - An engine doesnt support an object you are requesting natively?
> Evas should always fallback to software engine in that case, the
> drawing should be done on a user writable buffer and use the software
> engine there. So every engine should be reduced to a minimal set of
> functions:
>
> redraw() // redraws part of the engine output buffer
> blt_buffer() // blit a buffer into engine output buffer
> get_buffer() // get a buffer that the user can draw to
> get_native_buffer() // get a native surface so the object-engine can
> draw directly there
>
> - You want to build a private engine?
> You should set this engine's minimal functions, if you also want to
> provide accelerated objects for your engine, register a new object
> with your engine's name and fill the needed functions
>
> If we can settle down the above, which i think won't be that difficult
> to stabilize than the object's api, we would have gain a lot on
> flexibility. And then the object's api can be stabilized.
>
> Why i started enesim? because of the above cases, allow the user to do
> fancy graphics objects using enesim's primitives and direct rendering
> approach and also for easy benchmarking of the software engine.
>
> Do you think is a good idea?
actually this combines 2 things i had wanted for evas. and are good.
1. loadable extended objects (much like engines - you load a .so module that
provide an object) OR be able to define the object yourself much like a smart
object - but lower down.
2. defining custom object PAINT methods yourself in modules/callbacks instead
of smart objects which are really just ways of defining a group of basic
objects.
so pretty much evas's object world gets extended by this mechanism...
--
------------- 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
