On Thu, Jul 31, 2008 at 12:04 PM, Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> 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?
Sorry, but this should have gone to part ii. "i" and "i!" get mixed on my head
>
>
>> Which I'll leave for a 'part II' of this thread...
>>
>>
>> ____________________________________________________________
>> Click to become a designer and quit your boring job.
>> http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7L9Yyvs84mUKIe3vCf8GDVRRcB4RUunBX6sKcN8nFwKJPi/
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
-------------------------------------------------------------------------
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
