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