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?
> 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
