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 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 > -- 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
