I wrote:
> Carsten wrote:
>
>> .........
>>
>>> 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.
>>>
>>>
>> yup. i agree. (wow. we agree. i see hell freezing over! :))
>>
>>
>>
> :) Don't agree too quickly though. What are the pros and cons of this
> approach? There are other ways of doing this, ie. other apis that would allow
> for obtaining further vgfx support.. and one must also consider aspects such
> as the one I brought up on 'immediate-mode' drawing mechanisms. You and I have
> talked about this before, but never reached a satisfactory solution on how to
> obtain 'complex' drawings without having to have multitudes of evas objects
> (and
> my part III proposal for one way to get that via a special "gfx" object is
> just
> one possible way).
>
> Anyway, let me point out some pros to the 'vgfx' api I proposed:
>
> 1. It's an easy way to introduce such conepts and standard renderable
> primitives
> into evas, fitting well into evas' current "everything's an object" view.
> 2. It allows for re-use of current image and grad objects (ie. their defining
> properties) as paint sources, and can be easily extended to allow for other
> kinds of objects as paint sources if desired.
> 3. It allows for differentiation of transfoms, masks, filters for raster
> surfaces
> and (affine) transforms for vector objects.
>
>
> But it has cons as well - and in part this is related to the lack of an
> abstract immediate-mode api for doing vgfx (or other) rendering, and mechanism
> for creating new object types.
>
> If anyone has a different proposal for a 'vgfx' api for evas that would
> allow
> for the current rect,line,poly, and possibly some new objs (path say), this
> would
> be a good time to mention it. If not, then I'll give you another one shortly.
>
>
Let me then give an alternative version here, one that's a bit more
localized, ie. instead of a generic 'stroke/fill' api that would be supported
by current line, rect, polys, maybe text, some other objs... simply add a new
"path" object and let the previous api apply only to those, ie. one'd have
things like:
evas_object_path_fill_color_set
evas_object_path_fill_texture_set
evas_object_path_stroke_color_set
evas_object_path_stroke_texture_set
evas_object_path_stroke_weight_set
evas_object_path_draw_mode_set
and other refinements as seen fit (set affine transform, cap and join style,
winding
rule, etc).
This has the benefit of being localized to such objects. If it's desired
to
also extend this to lines, rects, polys, etc. then add similar relevant ones to
those objs.. eg. for lines one would have only the stroke related funcs.
____________________________________________________________
Boost your online security with a personal firewall. Click here!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oCGotdtDi28WpdHbeExnDwIJQDiPUFZLas9KG9zKKhJsus8/
-------------------------------------------------------------------------
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
