Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
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. Click now for huge savings on quality flooring materials! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nHbbmVw7dlV7pBWuGdbJSztaOloBUaq6teGtdqYAccN2uL6/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Thu, 31 Jul 2008 12:04:39 +0200 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:
> 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Tue, 29 Jul 2008 15:17:17 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: > > fair enough. are co-ords relative to object or canvas-global? i think we > > possible needs to make this object-relative? > > > > > > Object relative, ie. rel to obj's coord sys. - that works best for > evas' semantics of move, > resize of objs, and makes it easier to use as a retained-mode canvas. sounds good. > If the grad obj becomes 'bound' as a fill or stroke texture obj of > another (vgfx) obj, then the > fill geometry is taken rel to the textured obj coords. ok. sounds good. > In part, to allow for odd sized fills.. make it fit an odd sized > rect for example. hmmm. ok. > > hmm - ok, but these are very much linked. and addressing of vgfx needs to > > also address all the usual gradients used in vgfx (eg svg). :) but overall > > this seems to make sense above. > > > > Exactly. The 'downside' is that it breaks current evas api. But > better now while still > pre-alpha. Or, if it's decided best for it to be released first, then it > would have to wait > for a subsequent api-breaking new version. sure. this is why i'm wondering.. maybe - we just make a new class of vgfx object(s)? this means no break now... or in future... if we break now - it means still a lot of work to adapt to the breaks. :) -- - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Gustavo wrote: > Join late the discussion and badly starting with a top-post, I think > that trying to make Evas a canvas that supports both raster, vector > and maybe other (3d?) is bad, it will increase complexity, decrease > performance or both. > > Increased complexity, yes - in the sense that the api is somewhat larger and internals have to deal with more options. But performance would actually go up a bit when restricted to what's supported now. Actually, evas is really a vgfx canvas lib now - its image objects are really the same as a rectangle filled with a pixmap paint set to repeat, its grad objs similarly except filled with a gradient paint, its rectangle objs are just simple color filled rects, and similarly for its line, and poly objs. It's just a *very* simple vgfx canvas lib, exposing very few gfx abilities - no stroking (except for the trivial case of thin lines), no transforms, etc. Part of the reason I would've liked evas to have a kind of 'object model' for its core is precisely to better deal with a larger api and more complex internals that could benefit from differentiation of types. > If we add means to easily integrate with cairo, antigrain or other > vector libraries, maybe later add some ways to hook opengl surfaces, > it will be enough... it's already enough to SDL and lots of other > similar libs. It's a start, we can use it as a prototype, and it's > easier to to, basically just need to wrap these into images. > Things like cairo and antigrain and gl are immediate-mode gfx libs, you can "integrate" with them in various ways, but that's not providing more extensive *retained-mode* vgfx apis - ie. at the canvas level. That's what qt wanted and thus developed its qgraphicsscene, it's what gtk desperately wants and is trying with goocanvas, hippo canvas, pigment, clutter, it's what MS wanted and developed wpf/silverlight, it's what Sun wants and developed javafx, etc. Now, 2D vgfx has certain limitations, in particular it tends to lack support for projective transforms as many want in order to simulate basic 3D perspective kinds of effects. So, many want to add such support in various ways. Sun's JavaFx and Adobe's Flash are trying to add it via filters - since they've already committed to a straight 2d vgfx model for their 'canvas' model, clutter does it differently, qt allows them as transforms in certain ways, etc. But, it's what everyone wants in order to be able to create far "richer" graphical content - gui, presentation, or otherwise. Make order out of chaos with a new filing cabinet. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mgE4bXZ8GU3XaVSFciZwThaAt6T4aM77grt1U2os1YFxyhu/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Join late the discussion and badly starting with a top-post, I think that trying to make Evas a canvas that supports both raster, vector and maybe other (3d?) is bad, it will increase complexity, decrease performance or both. If we add means to easily integrate with cairo, antigrain or other vector libraries, maybe later add some ways to hook opengl surfaces, it will be enough... it's already enough to SDL and lots of other similar libs. It's a start, we can use it as a prototype, and it's easier to to, basically just need to wrap these into images. On Fri, Aug 1, 2008 at 7:03 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Jorge wrote: >> On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >> >>> Jorge wrote: >>> . >Let's consider the first part above only, and let me ask you this: > What > are the successful/modern gfx *apis* out there used for building guis, > what > are > their models, what are their primitives, how do they deal with > extensibility > or custom rendering. Take a look at say Flash, Silverlight, and Qt..., > and > let > me know what you see there. >There are others as well, but if you look at just these and give a > synopsis > of what's there, we can compare with evas and/or some possible other > thing > and > continue with greater insight and foresight. :) > > Im not sure if this comparative will be fair, the technologies you have named are products not libraries, is a full set of objects / classes / descriptions / whatever given as a whole to match a product, my mail was more in the sense of how to change things internally in evas that will allow several features externally. You might see evas as a product from several perspectives, from the object's POV: a library that only gives you a few type of objects: line, rectangle, polygon, images and gradients, text, etc and has a single clipping mechanism; but the idea was how to make more objects easily and still have the possibility to make those objects hw accelerated, not what others have that we dont. >>> Well, if you take out things related to gui builders and such, they're >>> really just 'libs', they expose a set of structures and funcs one can call >>> on - it doesn't really matter that they use different programming languages >>> have different runtimes, use classes, and whatnot. >>> What's common to them all is they build a retained-mode gfx model out >>> of a fairly standard immediate-mode vgfx drawing model. The method used to >>> obtain extensibility may vary somewhat, but at its heart it's derived by >>> letting you create new retained-mode 'types' via the use of the immediate- >>> mode drawing api to define how to draw new types (and some other aspects to >>> allow for specifying how to manipulate them in various ways). >>> >>> The point here being that evas lacks such an immediate-mode api, whether >>> vgfx or otherwise, which limits the way that new 'type' can be defined in >>> certain ways. One could try and build one such immediate-mode gfx api, say >>> a vgfx one like these, and use that.. or one can try and do it the other way >>> around -- use some set of objs the canvas supports (perhaps all) to 'define' >>> the immediate-mode gfx api indirectly, and feed this back in. >>> >> >> True, this is exactly what my first mail was about, have an immediate >> rendering api exposed. The question is, make evas expose it?, or >> handle it on a different lib? i've preferred the second choice and >> that's why i built enesim. >> >> >>> BTW, hw accelearated really has little to do with this per se, that's >>> just a matter of whether your obj rendering can be easily represented by >>> whatever hw accelerated api you have to work with. >>> >> >> Yes, but how can you do such a thing if the context of the accelerated >> api can't be retrieved? there's no way to do so right now, a smart >> object for example can't retrieve the gl context to do its own >> rendering when some event happens, so it is a must, or hw accelerated >> objects won't be possible. >> >> > > If you want such a thing, that explicit, then you need to expose specific > "native surfaces" -- that's the point of those. Otherwise, you don't need to > expose anything directly. You just 'expose' how to crete new, compound > renderings > from existing ones - if the existing ones are "hw accel" then so will be the > compound one. :) > > > > > Click for free info on college degrees. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l8WvE9WjyIpXSRhb6PKODGRN8lKbF8Q3Cn2OMy3CYXX5U6F/ > > - > 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Jorge wrote: > On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> Jorge wrote: >> >>> . >>> Let's consider the first part above only, and let me ask you this: What are the successful/modern gfx *apis* out there used for building guis, what are their models, what are their primitives, how do they deal with extensibility or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and let me know what you see there. There are others as well, but if you look at just these and give a synopsis of what's there, we can compare with evas and/or some possible other thing and continue with greater insight and foresight. :) >>> Im not sure if this comparative will be fair, the technologies you >>> have named are products not libraries, is a full set of objects / >>> classes / descriptions / whatever given as a whole to match a product, >>> my mail was more in the sense of how to change things internally in >>> evas that will allow several features externally. >>> >>> You might see evas as a product from several perspectives, from the >>> object's POV: a library that only gives you a few type of objects: >>> line, rectangle, polygon, images and gradients, text, etc and has a >>> single clipping mechanism; but the idea was how to make more objects >>> easily and still have the possibility to make those objects hw >>> accelerated, not what others have that we dont. >>> >>> >> Well, if you take out things related to gui builders and such, they're >> really just 'libs', they expose a set of structures and funcs one can call >> on - it doesn't really matter that they use different programming languages >> have different runtimes, use classes, and whatnot. >> What's common to them all is they build a retained-mode gfx model out >> of a fairly standard immediate-mode vgfx drawing model. The method used to >> obtain extensibility may vary somewhat, but at its heart it's derived by >> letting you create new retained-mode 'types' via the use of the immediate- >> mode drawing api to define how to draw new types (and some other aspects to >> allow for specifying how to manipulate them in various ways). >> >> The point here being that evas lacks such an immediate-mode api, whether >> vgfx or otherwise, which limits the way that new 'type' can be defined in >> certain ways. One could try and build one such immediate-mode gfx api, say >> a vgfx one like these, and use that.. or one can try and do it the other way >> around -- use some set of objs the canvas supports (perhaps all) to 'define' >> the immediate-mode gfx api indirectly, and feed this back in. >> > > True, this is exactly what my first mail was about, have an immediate > rendering api exposed. The question is, make evas expose it?, or > handle it on a different lib? i've preferred the second choice and > that's why i built enesim. > > >> BTW, hw accelearated really has little to do with this per se, that's >> just a matter of whether your obj rendering can be easily represented by >> whatever hw accelerated api you have to work with. >> > > Yes, but how can you do such a thing if the context of the accelerated > api can't be retrieved? there's no way to do so right now, a smart > object for example can't retrieve the gl context to do its own > rendering when some event happens, so it is a must, or hw accelerated > objects won't be possible. > > If you want such a thing, that explicit, then you need to expose specific "native surfaces" -- that's the point of those. Otherwise, you don't need to expose anything directly. You just 'expose' how to crete new, compound renderings from existing ones - if the existing ones are "hw accel" then so will be the compound one. :) Click for free info on college degrees. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l8WvE9WjyIpXSRhb6PKODGRN8lKbF8Q3Cn2OMy3CYXX5U6F/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Jorge wrote: >> >> . >>> >>>Let's consider the first part above only, and let me ask you this: >>> What >>> are the successful/modern gfx *apis* out there used for building guis, >>> what >>> are >>> their models, what are their primitives, how do they deal with >>> extensibility >>> or custom rendering. Take a look at say Flash, Silverlight, and Qt..., >>> and >>> let >>> me know what you see there. >>>There are others as well, but if you look at just these and give a >>> synopsis >>> of what's there, we can compare with evas and/or some possible other >>> thing >>> and >>> continue with greater insight and foresight. :) >>> >> >> Im not sure if this comparative will be fair, the technologies you >> have named are products not libraries, is a full set of objects / >> classes / descriptions / whatever given as a whole to match a product, >> my mail was more in the sense of how to change things internally in >> evas that will allow several features externally. >> >> You might see evas as a product from several perspectives, from the >> object's POV: a library that only gives you a few type of objects: >> line, rectangle, polygon, images and gradients, text, etc and has a >> single clipping mechanism; but the idea was how to make more objects >> easily and still have the possibility to make those objects hw >> accelerated, not what others have that we dont. >> > > Well, if you take out things related to gui builders and such, they're > really just 'libs', they expose a set of structures and funcs one can call > on - it doesn't really matter that they use different programming languages > have different runtimes, use classes, and whatnot. > What's common to them all is they build a retained-mode gfx model out > of a fairly standard immediate-mode vgfx drawing model. The method used to > obtain extensibility may vary somewhat, but at its heart it's derived by > letting you create new retained-mode 'types' via the use of the immediate- > mode drawing api to define how to draw new types (and some other aspects to > allow for specifying how to manipulate them in various ways). > > The point here being that evas lacks such an immediate-mode api, whether > vgfx or otherwise, which limits the way that new 'type' can be defined in > certain ways. One could try and build one such immediate-mode gfx api, say > a vgfx one like these, and use that.. or one can try and do it the other way > around -- use some set of objs the canvas supports (perhaps all) to 'define' > the immediate-mode gfx api indirectly, and feed this back in. True, this is exactly what my first mail was about, have an immediate rendering api exposed. The question is, make evas expose it?, or handle it on a different lib? i've preferred the second choice and that's why i built enesim. > > BTW, hw accelearated really has little to do with this per se, that's > just a matter of whether your obj rendering can be easily represented by > whatever hw accelerated api you have to work with. Yes, but how can you do such a thing if the context of the accelerated api can't be retrieved? there's no way to do so right now, a smart object for example can't retrieve the gl context to do its own rendering when some event happens, so it is a must, or hw accelerated objects won't be possible. > > > > Need Legal Advice - Click Here. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oI7JfSfRnwWLktNdwoXwReY8cQfuxnCoPKfCwc0YMeHM7UV/ > - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Jorge wrote: > . >> Let's consider the first part above only, and let me ask you this: What >> are the successful/modern gfx *apis* out there used for building guis, what >> are >> their models, what are their primitives, how do they deal with extensibility >> or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and >> let >> me know what you see there. >> There are others as well, but if you look at just these and give a >> synopsis >> of what's there, we can compare with evas and/or some possible other thing >> and >> continue with greater insight and foresight. :) >> > > Im not sure if this comparative will be fair, the technologies you > have named are products not libraries, is a full set of objects / > classes / descriptions / whatever given as a whole to match a product, > my mail was more in the sense of how to change things internally in > evas that will allow several features externally. > > You might see evas as a product from several perspectives, from the > object's POV: a library that only gives you a few type of objects: > line, rectangle, polygon, images and gradients, text, etc and has a > single clipping mechanism; but the idea was how to make more objects > easily and still have the possibility to make those objects hw > accelerated, not what others have that we dont. > Well, if you take out things related to gui builders and such, they're really just 'libs', they expose a set of structures and funcs one can call on - it doesn't really matter that they use different programming languages have different runtimes, use classes, and whatnot. What's common to them all is they build a retained-mode gfx model out of a fairly standard immediate-mode vgfx drawing model. The method used to obtain extensibility may vary somewhat, but at its heart it's derived by letting you create new retained-mode 'types' via the use of the immediate- mode drawing api to define how to draw new types (and some other aspects to allow for specifying how to manipulate them in various ways). The point here being that evas lacks such an immediate-mode api, whether vgfx or otherwise, which limits the way that new 'type' can be defined in certain ways. One could try and build one such immediate-mode gfx api, say a vgfx one like these, and use that.. or one can try and do it the other way around -- use some set of objs the canvas supports (perhaps all) to 'define' the immediate-mode gfx api indirectly, and feed this back in. BTW, hw accelearated really has little to do with this per se, that's just a matter of whether your obj rendering can be easily represented by whatever hw accelerated api you have to work with. Need Legal Advice - Click Here. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oI7JfSfRnwWLktNdwoXwReY8cQfuxnCoPKfCwc0YMeHM7UV/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Thu, Jul 31, 2008 at 1:44 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Jorge wrote: >> >> 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? >> > > Yes, I think it is a good idea (though there are also other > possibilities > for realizing such a generic concept). > > However, there are two things to consider here: > > One is that you still eventually need some sort of api(s) for 'objs' > that > you may want to support to start with in some 'canvas' model -- and that > includes > a semantics that would be consistent, and basic/standard kinds of gfx > concepts > that are well-known and widely used. > The other thing is the time and distance from such a more flexible > approach > to what's there now -- how to make both-ends-meet, or forget one and > continue with > the other. > > These are difficult questions to pin down and decide on. > > Let's consider the first part above only, and let me ask you this: What > are the successful/modern gfx *apis* out there used for building guis, what > are > their models, what are their primitives, how do they deal with extensibility > or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and > let > me know what you see there. > There are others as well, but if you look at just these and give a > synopsis > of what's there, we can compare with evas and/or some possible other thing > and > continue with greater insight and foresight. :) Im not sure if this comparative will be fair, the technologies you have named are products not libraries, is a full set of objects / classes / descriptions / whatever given as a whole to match a product, my mail was more in the sense of how to change things internally in evas that will allow sever
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Jorge wrote: > 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? > Yes, I think it is a good idea (though there are also other possibilities for realizing such a generic concept). However, there are two things to consider here: One is that you still eventually need some sort of api(s) for 'objs' that you may want to support to start with in some 'canvas' model -- and that includes a semantics that would be consistent, and basic/standard kinds of gfx concepts that are well-known and widely used. The other thing is the time and distance from such a more flexible approach to what's there now -- how to make both-ends-meet, or forget one and continue with the other. These are difficult questions to pin down and decide on. Let's consider the first part above only, and let me ask you this: What are the successful/modern gfx *apis* out there used for building guis, what are their models, what are their primitives, how do they deal with extensibility or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and let me know what you see there. There are others as well, but if you look at just these and give a synopsis of what's there, we can compare with evas and/or some possible other thing and continue with greater insight and foresight. :) Click for free info on online degrees and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nlXFvWpEiH1JgkNuaQWtD3XAbh0bvIMLSauNEiAzQFFY4P3/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Thu, Jul 31, 2008 at 12:04 PM, Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> 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 featu
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
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 draw
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Carsten wrote:
> On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>> 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, ...)
>>
>
> fair enough.
>
>
>> (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);
>>
>
> fair enough. are co-ords relative to object or canvas-global? i think we
> possible needs to make this object-relative?
>
>
Object relative, ie. rel to obj's coord sys. - that works best for
evas' semantics of move,
resize of objs, and makes it easier to use as a retained-mode canvas.
If the grad obj becomes 'bound' as a fill or stroke texture obj of
another (vgfx) obj, then the
fill geometry is taken rel to the textured obj coords.
>> (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.
>>
>
> why float? why not Evas_Coord ?
>
In part, to allow for odd sized fills.. make it fit an odd sized
rect for example.
>
>> (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).
>>
>> Which I'll leave for a 'part II' of this thread...
>>
>
> hmm - ok, but these are very much linked. and addressing of vgfx needs to
> also
> address all the usual gradients used in vgfx (eg svg). :) but overall this
> seems to make sense above.
>
Exactly. The 'downside' is that it breaks current evas api. But
better now while still
pre-alpha. Or, if it's decided best for it to be released first, then it
would have to wait
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
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, >>
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
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. :) > (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.). 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. ? Evas_Object *evas_objec_vgfx_polygon_add(Evas_Object *vgfx_obj); ... hmm. but then why should they have to live within a vgfx obj? -- - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> 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, ...)
fair enough.
>
> (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);
fair enough. are co-ords relative to object or canvas-global? i think we
possible needs to make this object-relative?
> (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.
why float? why not Evas_Coord ?
>
>
> (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).
>
> Which I'll leave for a 'part II' of this thread...
hmm - ok, but these are very much linked. and addressing of vgfx needs to also
address all the usual gradients used in vgfx (eg svg). :) but overall this
seems to make sense above.
--
- 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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
Gustavo wrote: > On Sun, Jul 20, 2008 at 8:58 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> Gustavo Sverzut Barbieri schrieb: >> >>> On Sun, Jul 20, 2008 at 8:29 PM, Peter Wehrfritz <[EMAIL PROTECTED]> >>> wrote: >>> >>> Jose Gonzalez schrieb: > (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. > > > I'm not familiar with evas internals, but maybe it'd be possible to have an evas_object_ellipse. I had several demands on irq for that. And if corners for rectangles are possible circles or ellipses shouldn't be much tougher than that, probably easier. >>> There is just one problem to these: resources to implement. :-( >>> >>> >>> >> Yup, i know that :). I just wanted to mention that there are people out >> there that do need/want that feature. I personally don't need it and >> probably many other don't need it either. So I wanted to bring it to mind >> that there are some people asking for it. Nothing more. >> > > I'd really like to see jose ideas and also filters in Evas. > Personnally I'll work on filters as soon as I have time, but I'd like > to see someone taking care of this gfx api... more specifically I'd > like to see someone integrate some existing gfx api in Evas, like > antigrain or cairo. > Most of the work involves getting this 'into' evas, the actual routines are fairly approachable - except for anything to do with thick stroking of arbitrary polys or paths.. that should be left til later, but hopefully Cedric and Jorge can get poly filling and also maybe work out a "path" obj api and again a fill implementation. I'll get most of the api I proposed in place, with a sample software implementation to work from -- no filters though, I'm leaving that for you and Carsten. :) As to external gfx apis for rendering to evas.. As I mentioned briefly before, it would be fairly straightforward to have both a "cairo" evas object and an "agg" one (maybe easier, I think this only draws to mem buffers?). One just needs a bit of extensibility to the engines to allow for 'object modules' (since these two would be examples of such). But you can also have it by getting the 'native surface' stuff finished off -- that would allow you to use various apis to render to targets like pictures, gl textures, etc. with whatever api you know that can draw to such one way or another.. you'd just then need to wrap this better via smart objs (with render-pre funcs) to get a more refined api if desired. Click here to compare top medical billing products, get demos, and quotes. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oiDnOGnerZMRqWIR1nfQppMoRKhaO0MAxacJ1whBNtd6Xve/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
Peter wrote: > Jose Gonzalez schrieb: >> (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. >> > > I'm not familiar with evas internals, but maybe it'd be possible to > have an evas_object_ellipse. I had several demands on irq for that. > And if corners for rectangles are possible circles or ellipses > shouldn't be much tougher than that, probably easier. > With the particular api I proposed here for rounded rect corners, one gets circles as a particular case (when the corner radius is >= the half the rect size). One could get ellipses too by modifying the api slightly to be of the form: void evas_object_rectangle_corner_radii_set(obj, float rx, float ry); So, keep looking, thinking, contrast and compare with others, etc.. and suggesting improvements. :) Compare Cell Phone Carriers- Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHH6UoBr8w1J7mUKmnlVzsmpCQgIxdUFjQeg0uDr5WmAOMQ/ - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
On Sun, Jul 20, 2008 at 8:58 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Gustavo Sverzut Barbieri schrieb: >> >> On Sun, Jul 20, 2008 at 8:29 PM, Peter Wehrfritz <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Jose Gonzalez schrieb: >>> (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. >>> >>> I'm not familiar with evas internals, but maybe it'd be possible to have >>> an evas_object_ellipse. I had several demands on irq for that. And if >>> corners for rectangles are possible circles or ellipses shouldn't be >>> much tougher than that, probably easier. >>> >> >> There is just one problem to these: resources to implement. :-( >> >> > > Yup, i know that :). I just wanted to mention that there are people out > there that do need/want that feature. I personally don't need it and > probably many other don't need it either. So I wanted to bring it to mind > that there are some people asking for it. Nothing more. I'd really like to see jose ideas and also filters in Evas. Personnally I'll work on filters as soon as I have time, but I'd like to see someone taking care of this gfx api... more specifically I'd like to see someone integrate some existing gfx api in Evas, like antigrain or cairo. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
Gustavo Sverzut Barbieri schrieb: > On Sun, Jul 20, 2008 at 8:29 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> Jose Gonzalez schrieb: >> >>> (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. >>> >>> >> I'm not familiar with evas internals, but maybe it'd be possible to have >> an evas_object_ellipse. I had several demands on irq for that. And if >> corners for rectangles are possible circles or ellipses shouldn't be >> much tougher than that, probably easier. >> > > There is just one problem to these: resources to implement. :-( > > Yup, i know that :). I just wanted to mention that there are people out there that do need/want that feature. I personally don't need it and probably many other don't need it either. So I wanted to bring it to mind that there are some people asking for it. Nothing more. - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
On Sun, Jul 20, 2008 at 8:29 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Jose Gonzalez schrieb: >> (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. >> > > I'm not familiar with evas internals, but maybe it'd be possible to have > an evas_object_ellipse. I had several demands on irq for that. And if > corners for rectangles are possible circles or ellipses shouldn't be > much tougher than that, probably easier. There is just one problem to these: resources to implement. :-( -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I!.
Jose Gonzalez schrieb: > (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. > I'm not familiar with evas internals, but maybe it'd be possible to have an evas_object_ellipse. I had several demands on irq for that. And if corners for rectangles are possible circles or ellipses shouldn't be much tougher than that, probably easier. Peter - 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
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Just a couple of other remarks on these two (parts I, II) proposals: Like the proposed gradient obj api function that sets an (affine) "fill_transform", there would be a similar one to set such on an image object: void evas_object_image_fill_transform_set(obj, Evas_Transform *t); Note that this is NOT the same as transforming the object itself.. that's a separate thing (as would be raster-based filters one could apply on general objects). Such 'fill_transforms' should be used mostly for the purposes of using the image object as a texture - not for transforming "an image". The best way to do that would be via an object transform (which can then be a general projective one) and by having an image api func that would set the image obj's 'fill-policy' to none (or something like that), meaning that all image 'fill' attributes are ignored and the image is then always scaled to the size of the obj - ie. the image obj then acts like "an image" rather than like a plain rect which is being fill-textured with an image. But all this will take a bit longer to be implemented due to the fair amount of re-structuring of evas image internals needed to add support for it. If anyone is willing to try and work on that part in the meantime, let me know. One other api func that will be needed with general stroking (and also later when objects might support transforms or filters) is an api func to obtain an object's 'bounds' - ie. the actual bounding rectangle of the obj as drawn on the canvas. void evas_object_bounding_rect_get(obj, Evas_Coord *x, *y, *w, *h); This will be needed internally as well for correct 'hit detection' of such modified objects (eg. of thick stroked lines, polys,... transformed objs, etc). Great pay, great benefits, rewarding. Click for information on a healthcare career. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oH0aMuCCxm9AWWu0rLnlZhHMOGuyhEcYIxHg0zbWPFduCZi/ - 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
[E-devel] Proposed evas gfx api changes and additions - part I!.
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). (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. Click to consolidate your debt in minutes, stop late or over-limit fees, pay less. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2bkjb956ElxjIhRRrqe1OG1E6WbsoH6rpBrTpg9m4hiCTW/ - 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
[E-devel] Proposed evas gfx api changes and additions - part I.
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).
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
