Carsten wrote:
> On Thu, 17 Jul 2008 05:58:24 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>> Ok, now for a proposed api for evas "vgfx objects" -- a very simple
>> one, but general enough to allow for the overwhelming majority of vgfx uses
>> (and certainly ones for most 'real-time' use in evas).
>>
>> Again, by evas "vgfx objects" we mean evas objects that can be "filled
>> and/or stroked" (eg. lines, rects, polys, paths, ... maybe text) with a color
>> or a "texture" (aka: a paint or pattern).
>>
>
> or maybe even more simply: "any primitive uses for svg rendering" might be an
> apt goal... :) the important bit is the actual rendering code... and back-end.
> once done it can be exported to objects no problem. :)
>
>
The api should be suitable for that, and for other 'kinds' of
objects that may want to
support it - even if they're not exactly 'vgfx' objs in the usual sense.
Let's back up here for a second and review this kind of stuff, as
it'll make some of
what's below a bit more clear.
What's normally considered 'vgfx' has really only one rendering
primitive - what's
called a generic "path". These can be drawn in one of two basic ways -
they can be "stroked"
or they can be "filled".. and that can be done with different kinds of
'paints' (what I've called
textures, others patterns, etc) - a color, a gradient, or an image - to
cover the areas included
by the stroking or filling of the shape. There are other things related
to this, but that's the
basic jest of it.
Every particular 'path' you define can potentially be used to
define an 'object',
say a rectangle, a triangle, a line, a circle, a heart-shaped thing, a
star-shaped one,
a circle with a square 'hole' inside it, .... whatever. It's an
abstraction on top of the basic
path primitive to define specific 'kinds' of figures that you may want
to isolate, and
some may have ways of controlling various aspects, even seem to be something
not directly a 'path', etc.
But one can turn this around too, at a high level, and implement a
semantics for
specific objs that may possibly support the notion of being able to be
'stroked' or 'filled'
with a paint/texture. You don't have to implement those via a
path-rasterization algo.
>> (1) For "filling" of supported objs:
>> *******************************
>>
>> void evas_object_fill_color_set(obj, r,g,b,a);
>> void evas_object_fill_texture_set(obj, Evas_Object *texture_obj);
>>
>> Where 'texture_obj' is restricted to be an image or a gradient obj (no
>> others for now). Also, no fill-texturing of an image or grad obj. I think I
>> briefly explained the interpretation of this before - ie. image or grad objs
>> are really equivalent to a simple rectangle being flled with image or grad
>> texture, where the 'texture' part is given by fill geometries and such.. So,
>> when these objects are set as texture_objs of vector objs, all general object
>> properties are ignored and only the 'fill' properties are used - except that
>> the fill geometries' coord system is now taken rel to the textured obj's
>> origin.
>>
>>
>>
>> (2) For "stroking" of supported objs:
>> ********************************
>>
>> void evas_object_stroke_color_set(obj, r,g,b,a);
>> void evas_object_stroke_texture_set(obj, Evas_Object *texture_obj);
>>
>> These are similar to above for the fill.
>>
>> void evas_object_stroke_weight_set(obj, Evas_Coord weight);
>>
>>
>>
>> (3) For determining whether to fill and/or stroke supported objects:
>> ***************************************************************
>>
>> void evas_object_draw_mode_set(obj, int draw_mode);
>>
>> Where 'draw_mode' is one of: EVAS_DRAW_STROKE, EVAS_DRAW_FILL, or
>> EVAS_DRAW_STROKE_FILL.
>>
>>
>> More api funcs can be added to obtain fuller vgfx support, but this is
>> actually a good chunk of it (just need a bit on cap styles, join styles, and
>> dashed-stroking, but not much else really that would be reasonable here).
>>
>> It doesn't cover the other proposed desire to change the polygon object
>> 'points' api, nor does it cover a possible "path" object api (which I would
>> suggest be given in the same manner as that proposed for polys, ie. *set* a
>> "path description" which consists of some means of defining the path).
>> Nor does it cover possibly setting (affine) transforms on the vertex-
>> geometries that might define such vgfx objects.. leave that for later.
>>
>>
>>
>> (4) Extensions to the current rectangle obj api:
>> *******************************************
>>
>> void evas_object_rectangle_corner_radius_set(obj, float r);
>> void evas_object_rectangle_corner_style_set(obj, int corner_style);
>>
>> Where 'corner_style' can be one of EVAS_CORNER_ROUND or
>> EVAS_CORNER_BEVEL.
>>
>>
>> void evas_object_rectangle_corners_set(obj, Evas_Bool tl, Evas_Bool tr,
>> Evas_Bool bl, Evas_Bool br);
>>
>> The corners to apply the style to, or leave squared off (default).
>>
>> Rectangles can be filled and/or stroked, but the stroking will be
>> defined to increase inward - though one could also add an api for deciding
>> whether to have it centered on the rect, or increase inward or outward.
>>
>
> hmm. ok - you havent covered all the vector gfx primitves (polygon, polyline,
> line, bezier curve/path, ellipse etc.).
>
>
It would cover all those, and any others that may want to support
whatever part
of this general 'stroke/fill' api. I just haven't proposed an api for
defining path objs,
polyline objs, heart objs, star objs, or anything else.. and would
prefer that Cedric
and Jorge do so if they wish.
The implementations of any and all of this is open.
> maybe.. just an idea we have a new vgfx object. leave existing objects alone.
>
> Evas_Object *evas_object_vgfx_add(Evas *evas);
>
> and like image objects.. you can set a .svg to be the content... OR you can
> add
> the content yourself? ie add polygons, curves, lines, set what paths clip
> what... etc. ?
>
>
That's a possibility too, and I've mentioned this as well. It's a
further and useful abstraction,
those are objs that might not support 'stroke/fill' since they are
compound, though they could support
affine transforms. The point of having a stroke/fill api is to be able
to also have various kinds of such
vgfx 'primitives' as evas objects. That's extremely useful on its own
for basic gui uses.
> Evas_Object *evas_objec_vgfx_polygon_add(Evas_Object *vgfx_obj);
> ...
>
> hmm. but then why should they have to live within a vgfx obj?
>
Exactly. It's useful to have a variety of 'objs', some compound,
some primitive, etc.
I think both an "svg" object (set an svg file/group, support affine
transforms) and a "cairo"
object (an implicit cairo surface to draw on, set updates, etc), and
other such, would be very useful.
____________________________________________________________
Hotel pics, info and virtual tours. Click here to book a hotel online.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmK0guCYhBxdIYfm1Pv6NanJItnZDjtdO7ohlydP2y8aQ0/
-------------------------------------------------------------------------
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
