I wrote:
>
> Cedric wrote:
>> I have just one question should we expose the floating point
>> coordinate to the engine, or if we give it the list of points inside
>> the object geometry. The first solution will potentially share more
>> code between engine, but it could perhaps limit some optimisation. The
>> second solution will require much more code, but could perhaps give us
>> more engine specific optimisation and later possible improvements when
>> we add transformation (I currently don't know any, just that with more
>> information you can often do more smart choice).
>>
>>
>
> Think about what one needs to do with these guys to get the
> 'usual' amount
> of support for vgfx: You need to fill them with a color, and/or with
> an image or
> gradient as a 'texture' (aka 'pattern'), you need to stroke them with
> similar,
> with different stroke weights, with possibly end caps, with possibly
> join styles,
> with possibly dash patterns, ...
> I wouldn't sweat the deatils of what you start of with now, since
> there's
> almost near certainty that whatever it is, you'll end up changing it
> several times. :)
>
Of course one doesn't have to support *every* vgfx aspect out there,
and indeed various libs support different amounts. I'd say that evas should
support most of the simpler stuff at first, and leave it open to extend
further if desired.
Note that, as I've stated on other ocassions, one can also have special
'canvas' or 'surface' like gfx objects, including ones that expose particular
apis - eg. a "cairo" object exposing things like an implicit cairo surface to
draw to via the cairo api, an "svg" object exposing whatnot.. maybe just set
an svg file/group with suitable transforms.. maybe modify via the svg dom api,
and others such... many special ones are possible.
But as to a possible api for evas vgfx objects, let me give you one
possible start (only 'set' api funcs here), and let's consider these as
applying to rects, polygons, lines, and a possible future "path" object,
and let's also consider rectangle objects as a 'special' kind of vgfx obj
which, since it's not directly define via vertex/path data, can have some
slightly different semantics for the interpretation of some of these.. and
note that some objects can only be 'stroked' like lines, and some objects
maybe can only be 'filled', like possibly text... But anyway, here we go.
"Fill" related apis:
void evas_object_fill_color_set(obj, r,g,b,a);
void evas_object_fill_texture_set(obj, texture_obj);
// Where 'texture_obj' is restricted to be an image or gradient obj.
// Note these texture objs have a 'fill region' associated with them
/ and that's used for texturing the obj. The texture_obj's own size
// becomes effectively unbounded, ie. ignored, the fill is extended
// to cover the obj. In effect, fill texturing a rect object with an image
// or gradient obj, is largely equivalent to the image or gradient obj itself.
// or gradient obj, is largely equivalent to the image or gradient obj itself.
Maybe also a fill winding-rule.. but let's leave it for now - very simple.
"Stroke" related apis:
void evas_object_stroke_weight_set(obj, weigth);
void evas_object_stroke_color_set(obj, r,g,b,a);
void evas_object_stroke_texture_set(obj, texture_obj);
// Stroking grows centered on the figure, except for rectangles where
// it grows inwards towards the interior of the rect. Don't ask why.
There are others that are useful and not too difficult to implement
(eg. caps styles and such), but let's leave it there for stroking as this
would cover a lot of the useful stuff.
"Stroke and/or Fill" api:
void evas_object_draw_mode_set(obj, mode);
// Where 'mode' is one of: EVAS_DRAW_STROKE, EVAS_DRAW_FILL, or
// EVAS_DRAW_STROKE_FILL.
I'd also consider the following rectangle_object specific extensions:
void evas_object_rectangle_corner_radius_set(obj, float r);
void evas_object_rectangle_corner_style_set(obj, style);
// Where 'style' can be one of EVAS_CORNER_ROUND or EVAS_CORNER_BEVEL.
// One can also consider further kinds of styling of such corners,
// including deformations between these.
void evas_object_rectangle_corners_set(obj, Evas_Bool tl, tr, bl, br);
// The corners to apply the style to, or leave squared off (default).
Ok, that's all I'd start off with. There's a lot more stuff one can
expand on, but these would be a good start.. and modulo general polygon
stroking (which is a bit involved), they're actually not too difficult
to obtain. Add a "path" object, or let people generate approx polys from
their own (simple) paths (they'll need to regenerate if they do any up-scaling),
and you have a large chunk of a useful, real-time, simple evas vgfx-obj api
for guis.
I'd suggest a general object transform and mask api as well --
one that I think could be useful, efficient, and feasible to implement..
but I'm going to rest my case on those and leave the filter-pipeline
enthusiasts to deal with these. :)
____________________________________________________________
Sweepstakes!!!
Enter for your chance to WIN a summer spa getaway!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UjkSyAUntbnFCcbsGeH48JZA3ZtvbjitqZzSCvaucaT4Jp/
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
