On Tue, 29 Jul 2008 15:17:34 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> 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. sure! path... but you need all the calls to manipulate/create that path. and then there is clipping to paths to be done to (tho api to set clipping is done) but we'd need multiple kinds of clipping (clip, difference, intersection, exclusion...). :) > > 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, aha! that was what was missing! :) why i was mentioning it! :) > 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. cool. i'm all open to this being added to evas. :) > > 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. yeah - much like image objects - vector objects (that could be loaded from svg.. or a bunch of other files in theory) would be most useful. > > 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. yup. i agree. (wow. we agree. i see hell freezing over! :)) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
