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