On 9/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Jorge writes: > > > > I tell you what, let me look things over a bit during the > > > weekend, and if you like you and maybe Jorge can do the same... > > > maybe discuss it with others on the list who have some experience > > > with evas/objects/engines.... and we can take it up again on Mon > > > or Tues, and maybe Carsten can add some thoughts. > > > > i think we need to actually write what are our main goals with > > this, not only "rewrite some internal evas stuff". what i would > > like to have on evas is: > > > The issue is not to "rewrite some internal evas stuff" just > for the heck of it.. It's to fix a large number of aspects that > prevent the lib from scaling to support much more than what it > now does.. and prevent it from supporting even slight additions > without a large amount of effort.. and a few other things as well > that need to be fixed. > Unfortunately, to do this right means re-writing much of > the internals.. no simple little piece-meal 'patches' are going > to do it. > > > - simplify the creation of render engines. > > - support font engines. freetype should be one of them. > > - make objects be modules too > > - actually make objects render by themselves to an argb buffer > > - split huge headers into smaller ones. > > - support for a mechanism to make evoak work nicely with evas > > (callbacks, remote engine, whatever) > > - (add more) > > > > Much of this cannot be done in 'isolation' without a coherent > view of the final target design/capabilities that one wants the lib > to have. > > Let me address some of the above, as I see things... > > -- "support font engines. freetype should be one of them." > > I hope you realize what a pain font/text related stuff is! > I would say that this is not really that important right now, but is > certainly something to be kept in mind.
yes i do, that's why i wrote it :) the font handling on evas is kind of messy i guess because fonts handling by definition is actually messy, dunno much of this topic either, but i think a "font engine" is in charge to actually render the glyphs (i know there might be other functions but this i guess is the most important), so if in a future we would like to write our own font format this is would be the base of it. > > Long ago (or so it seems), I wrote font loaders for imlib2. > > At the time, freetype didn't support xfonts so I had loaders > for ttf fonts, xfonts, and fnlib fonts. I also had "font stylers", > which were also loadable modules and could 'style' any input glyphs.. > I had something like three such 'stylers' I think. > They could layer/composite glyphs, texture them with images > or grads, bumpmap them with light sources, shadows, rotate/skew them, > modify glyph advances, and other things.. xml files described what > they would do. > Unfortunately, I had to break the imlib2 api to do this > since it wasn't adequate for the needs of such beasties... Carsten > may still have the code for this somewhere as I sent it to him then. > > > -- "simplify the creation of render engines." > > This, per se, needs at least three things to begin with, > as I mentioned earlier: get/put and composite argb buffer functions, > and also a generic cache mechanism. This latter is needed for several > things.. least of all to cut back on needless code duplication. > > I hope everyone knows that if you call the evas api function > "evas_image_cache_set(evas, size)" you will not only be setting the > cache size for that 'evas' instance, but also for every evas that > uses the same engine. > If some code sets the cache size to 0 for one software-x11 > evas canvas, they will have flushed the image cache and set it to 0 > for every software-x11 evas the program/lib deals with, and also > flush the more "common" image cache that all buffer-evases use. > If some code somewhere sets the image cache to 0 for one > buffer evas instance, it will flush the image cache for all such > and there will be no further image caching by any buffer evas, or > ecore sub-canvases, until some other code resets the cache size for > one buffer evas somewhere... > > I wrote a simple quick one once as well, using the current > evas hash/list implementation and following the basic pattern used > for image caching, etc.. It had a fairly straightforward api which > Carsten and I discussed somewhat. > But to stick this into evas requires a moderate amount of > work, and as no one seems concerned with the above caching issues > or with the internal code duplication, so I just let it go. > This kind of thing is something that ecore could use as well > though. > > Now, as to the get/put and composite funcs.. that's fairly > straightforward.. although to do this at all would be best done in > conjunction with the move to premul data, which together forms not- > so-small an amount of work. > > > -- "make objects be modules too." > > Ahhhhh.... This is something I've been mentioning for months, > but no one seemed to care about. I sent Carsten some preliminary notes > on this, some data structures and design preliminaries needed, etc.. > But it requires a lot of work to fully realize this - to make > it work in tandem with loadable types and arbitrary engines.. and no > one seemed much interested in this. Should I further pursue such a > large re-write, which no one has much enthusiasm or support for, and > then just throw it over...? > > > -- "split huge headers into smaller ones." > > Which headers? For what internal changes????? well with headers i meant the idea i wrote on another mail. evas has basically three headers: Evas.h evas_private.h and evas_common.h (there are some more i know) so if we would like to export some evas internal functionality in some way to the evas developer (engine writer, module writer, filter writer, whatever) a good split of headers would be good. i do have a version of evas with just this "headers stuff" modified and works ok :) it would be a first step to allow "outside modules" and a good thing to make our code cleaner. > > > -- "support for a mechanism to make evoak work nicely with evas > (callbacks, remote engine, whatever)" > > A truly nice capability.. :) > > > -- "(add more)" > > Just the above is quite a bit.. It would make this part much > easier. Many things are actually fairly simple to do.. it's adding > them to evas with its current internals that is "difficult". > > > > > > > > This is the kind of thing that would really benefit from > > > having an "experimental" CVS version of evas.. Understand though > > > that it would mean quite a bit of work to get it all done.. a lot > > > has to be re-written. > > > > indeed, a cvs dir to experiment with evas would be nice, maybe > > i can put it on proto? > > > > It's going to be just about impossible to do this any other > way than with a separate CVS version to work with. > > To me the main issue is not really a 'technical' one pre se, > it's do people really want, and want to help with, such changes? > > > jose. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
