Re: [E-devel] Evas Evoak future changes
On Fri, 8 Sep 2006 08:15:38 -0500 [EMAIL PROTECTED] babbled: On Fri, Sep 08, 2006 at 09:40:08AM +, [EMAIL PROTECTED] wrote: Now, unfortunately, this discussion came up at a time when people are busy with e17... in particular, the 'owner' of evas is especially so. So basically, either people proceed without him (with a 'branch' or whatever), or they can wait around, or they can let things go. Or they can discuss ideas, get feedback, etc. I think this last was what Jorge was attempting to get started.. good timing or not.. and I guess he hoped that at least raster would have joined in (even if he did say that he was too busy to do so). I'd suggest maybe keep ideas in mind, let them develop, see what one might need, etc.. until things quiet down a bit on the release front. jose. This was more the point I was trying to get across. I didn't mean to sound like I was discouraging you three from working on evas. I'm all for branching evas and having ya'll work your magic :) (lack of time results in short emails that often don't properly convey the tone of voice i intended. for that, again, i apologize) take care, rephorm and here i come at the end of the tread... FINALLY! :) (i am hoping i can now mark off this entire thread in hit). ... so... the work jorge is doing is very interesting. it is basically the ability to virtualize right below the api level and punt off to somewhere else (in this case a server). this is most interesting but unfortunately touches just about every bit of api and has some really tricky parts to it. i think having this work in another branch is fine - i have no problems with that, but it will cause problems in merging later. what i think is a good idea is that this happens in a branch and jorge merges in changes from evas's head branch regularly so the merge back is as painless as possible. i think this work should happen - it has some exciting possibilities. it just needs to happen in a way that won't affect stability and correctness of the head evas branch :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Nathan writes: On 9/6/06, Jorge wrote: well i dont totally agree, i mean, i started this discussion with some ideas i would like to have implemented on evas, i guess jose thinks the same. so this thread is to actually THINK and WRITE what are the future goals of evas (that's why the topic is called like that). and looks like im not the only one with some evas' ideas . I don't think rephorm was advocating that no work happen on evas, but that as far as developer resources, people should be encouraged to work on the window manager and other higher level work. I raised some concerns related to this, but it was not to imply that people should divert from e17 (or anything else) and should begin working on evas instead. if e17 is a priority i agree but im not actually coding it, instead i would like to settle down the base of what will be the next evas. what other opinions can we receive but yours? (developers and evas users). so if this ends to be actually a branch ill be glad to code it, e17 will still use current evas branch and everyone happy :) we can code in parallel. might be double effort to then merge both branches, but that's why branches are for :) I agree with you on this. Some people simply have no interest in working on the window manager but have a lot of interest in graphics, widgets, or some other related subsystem. That's certainly a natural thing, and allows for growth in various areas that are needed. If e, in the large sense, is to really advance, then that is of utmost importance.. a wm alone will not do it. In fact, I would say that good gui-toolkit(s) and filemanager(s) are more important in the long run. basically i think evas api wont change too much, the premul color thing will end up with another layer between the colors used on edje and the current colors used (current color space - premul), what we are looking for is an evas internal refactoring. I think the most reasonable approach going forward would be to complete the color space conversion to premul, then branch of stable and development tracks. The stable branch would maintain a relatively stable API until release in order to allow development the window manager and other higher level API's. The development branch can incorporate the various ideas you and Jose have proposed without disrupting other development. Depending on when the development branch reaches a usable point, discussion can move to deciding if it's suitable for merging to stable and converting existing software to use the API changes or if it should be worked on further for an evas 2.0 candidate. There's really no issue here of api breakage. Some semantic changes will be needed for premul, and we've discussed and agreed on those already. There are two separate but related aspects here that are what Jorge, Cedric, and I referred to. 1) Evas 'internal' changes: Many reasons for this that are purely internal issues. 2) Evas 'external' additions: New capabilities, possibilities, etc.. The above 'internal' changes make this far more doable. For me, it's actually pretty much essential. In turn, this part can greatly affect the nature of the above internal changes. This part could mean more api functions, more libs, ... But it's unlikely to mean break some current set of api functions, or at least I personally don't see that as needed. Now, unfortunately, this discussion came up at a time when people are busy with e17... in particular, the 'owner' of evas is especially so. So basically, either people proceed without him (with a 'branch' or whatever), or they can wait around, or they can let things go. Or they can discuss ideas, get feedback, etc. I think this last was what Jorge was attempting to get started.. good timing or not.. and I guess he hoped that at least raster would have joined in (even if he did say that he was too busy to do so). I'd suggest maybe keep ideas in mind, let them develop, see what one might need, etc.. until things quiet down a bit on the release front. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On Fri, Sep 08, 2006 at 09:40:08AM +, [EMAIL PROTECTED] wrote: Now, unfortunately, this discussion came up at a time when people are busy with e17... in particular, the 'owner' of evas is especially so. So basically, either people proceed without him (with a 'branch' or whatever), or they can wait around, or they can let things go. Or they can discuss ideas, get feedback, etc. I think this last was what Jorge was attempting to get started.. good timing or not.. and I guess he hoped that at least raster would have joined in (even if he did say that he was too busy to do so). I'd suggest maybe keep ideas in mind, let them develop, see what one might need, etc.. until things quiet down a bit on the release front. jose. This was more the point I was trying to get across. I didn't mean to sound like I was discouraging you three from working on evas. I'm all for branching evas and having ya'll work your magic :) (lack of time results in short emails that often don't properly convey the tone of voice i intended. for that, again, i apologize) take care, rephorm - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
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. 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. Ah 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
Re: [E-devel] Evas Evoak future changes
On Wed, Sep 06, 2006 at 07:34:48AM +, [EMAIL PROTECTED] wrote: snip It's going to be just about impossible to do this any other way than with a separate CVS version to work with. A branch should work, right? 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? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Maybe we just need to clarify what changes are planned when we release so that potential users of the lib will be aware of them? rephorm. - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Brian writes: 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? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. Maybe we just need to clarify what changes are planned when we release so that potential users of the lib will be aware of them? 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] wrote: Brian writes: 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? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I realize this. I never said anything about lib fiddling :) I totally agree that evas needs some work. I would love true loadable objects with a well defined interface so we can more easily extend things. All I'm saying is that we have very little dev power to divy up between everything that needs doing. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. I think we need to get e17 out, and THEN bump this up to top priority. (With the exception of pre-mul, which, due to the API shift, should probably be done before any evas release). However, that said, we're a pretty unguided mass of transient coders, with different goals and desires. Maybe its just my lack of familiarity with evas internals that forms my opinion. :) rephorm. - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On 9/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] wrote: Brian writes: 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? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I realize this. I never said anything about lib fiddling :) I totally agree that evas needs some work. I would love true loadable objects with a well defined interface so we can more easily extend things. All I'm saying is that we have very little dev power to divy up between everything that needs doing. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. I think we need to get e17 out, and THEN bump this up to top priority. (With the exception of pre-mul, which, due to the API shift, should probably be done before any evas release). However, that said, we're a pretty unguided mass of transient coders, with different goals and desires. Maybe its just my lack of familiarity with evas internals that forms my opinion. :) well i dont totally agree, i mean, i started this discussion with some ideas i would like to have implemented on evas, i guess jose thinks the same. so this thread is to actually THINK and WRITE what are the future goals of evas (that's why the topic is called like that). and looks like im not the only one with some evas' ideas . if e17 is a priority i agree but im not actually coding it, instead i would like to settle down the base of what will be the next evas. what other opinions can we receive but yours? (developers and evas users). so if this ends to be actually a branch ill be glad to code it, e17 will still use current evas branch and everyone happy :) we can code in parallel. might be double effort to then merge both branches, but that's why branches are for :) i agree when you say that evas is good enough for the libs/apps we have. but if would like to actually be able to code more fancy/good stuff evas has to evolve, and must evolve from an evas developer point of view (possibility to extend evas functionality) basically i think evas api wont change too much, the premul color thing will end up with another layer between the colors used on edje and the current colors used (current color space - premul), what we are looking for is an evas internal refactoring. rephorm. - 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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
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. Ah This is something
Re: [E-devel] Evas Evoak future changes
On Thursday, 07 September 2006, at 04:57:31 (+), [EMAIL PROTECTED] wrote: just make it clear that when I 'criticize' evas' this or that, and whatnot.. it's not to criticize Carsten's work on evas - not by any means. Criticism doesn't have to be negative; constructive criticism is always appreciated. I know Raster appreciates your ideas/suggestions and your continued support/help with evas. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- Greatness is never appreciated in youth, called pride in mid-life, dismissed in old age, and reconsidered in death. Because we cannot tolerate greatness in our midst, we do all we can do destroy it. -- Lady Morella (Majel Barrett Roddenberry), Babylon Five - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
indeed, a cvs dir to experiment with evas would be nice, maybe i can put it on proto? or in another branch Vincent - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
... This would be true on PC, but on embedded device you will really like the idea of using as much as possible the hardware. Preserving evas ability in this area is really something important in my opinion. indeed, but there's a problem. evas manages internally always ARGB data, so to actually use the hw on evas the hw should support argb blittings. on embedded devices it is difficult to find support for 32 bit image data, most of them are 16 bit, this is changing and will change on the future. But the main reason for this re-design is really to allow for both modular engines AND modular objects to work.. not just to make it easier to add new engines supporting the current set (or an extended set) of objects and/or their properties - though that is certainly an added bonus. Each object type is thus a collection of modules, one for each engine it may want to provide an optimized implementation for.. But it must provide at least one module - the 'generic' one. The mechanism is then setup so that this generic module can work with ANY engine - so long as the engine provides the required buffer functions, and its general gfx context 'derives' from the 'generic' one. This sound really good. Did you already start some work ? After playing a bit with evas engine, a lot of what you propose make sense and would really like to help in this area if I can. great =) Cedric - 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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Jorge writes: ok! now i understand what you mean on the first place, i totally agree with you. in the current evas in order to make a new engine you have to define all the current engine functions or at least inherit the software engine (almost all engines do that), this is pointless because the objects (besides the line and rectangle) are not common in all engines, another example: almost all engines (ie. X, dfb, sdl, cairo, whatever) do support images but not the current image object api (border_set, ...) . so as you said if you plan to add stroke to the line object it will be even more difficult to find a backend that supports what evas needs, so you still depend on the software engine to do the work. maybe the solution is to have just the functionality you said on the engine side: blit/copy from/to target surface, it may look very similar to what cairo defines as a backend. Well, the get/put functionality is actually a kind of last resort thing. It's generally very slow to 'get' from a display target.. but it would be there for very particular obj types that need an argb copy of what's already been rendered in order for it to 'do its thing'.. Most objs would not need this. What they would use is some form of compositing to the display target, or to a target specific buffer surface. For this we'd have two sets of functions - one set that 'directly' composites a triple (argb buf, a8 buf, color) to a target surface.. and one set that involves target specific buffers. Many engines have some sort of native notion of a 'buffer' that one can get/put data to, which they can composite to a target surface.. eg. xrender has 'pictures', gl has at least 'textures', etc.. and usually this compositing can be done with some 'transform' (scaling, rotating, shearing,..) being specified. Most of the hardware accelerated aspects that evas needs really come from this compositing step. So what one can do is to realize one's object to an (argb buf, a8 buf), and 'put' this (plus maybe the global context color) on an engine provided buffer of some sort. Then let the engine do the compositing of this to the target surface. One can cache such buffers and only need re-generating/ putting the data from the obj when state changes require it.. and thus obtain some good performance on that part - even though you know nothing about what the object may be doing to realize itself onto the argb/a8 buffers that it puts on engine provided buffers. Some tests I've run show that even when the engine supports functions for drawing things like sub-pixel positioned polygons, it's actually faster to draw these in software and use the above. When I say faster here, I mean not 10% or 30% faster.. I mean it's like 20 or more times faster. But the main reason for this re-design is really to allow for both modular engines AND modular objects to work.. not just to make it easier to add new engines supporting the current set (or an extended set) of objects and/or their properties - though that is certainly an added bonus. Each object type is thus a collection of modules, one for each engine it may want to provide an optimized implementation for.. But it must provide at least one module - the 'generic' one. The mechanism is then setup so that this generic module can work with ANY engine - so long as the engine provides the required buffer functions, and its general gfx context 'derives' from the 'generic' one. just one last thing, with this changes in mind, in what level would you insert the object engine (i guess it wont be called like that anymore) the idea of making a layer above the object functions (API object functions, _move, _resize, _image_file_set, rectangle_add, etc) was to avoid duplicating functions on evoak. evas still maintains the state of objects but after a state change the object engine (evoak engine) sends a protocol's command to the evoak server. the main idea is to set up callbacks for any object state change. ... The obj-engine sounds nice.. :) I just think that exporting many of these things may just be too pre-mature - regardless of how the objs and engines and such eventually end up looking. i agree, so a good previous design will be usefull. It would.. and it would make it easier to write any engine without having to worry about giving specific implementations of some set of objects at first.. Also, it would give loadable obj types.. something which is very desirable (for various reasons). Altough adding render-pre/post functions to smart objects would also help in speeding self-rendering 'external' objects, having the ability to put some of these as loadable obj-types would be more efficient and faster - and allow for whatever engine specific optimizations to be written as well. However, I just don't see myself sending this imminently. There's a lot still left to
Re: [E-devel] Evas Evoak future changes
On Friday 01 September 2006 08:02, [EMAIL PROTECTED] wrote: Jorge writes: ... Many engines have some sort of native notion of a 'buffer' that one can get/put data to, which they can composite to a target surface.. eg. xrender has 'pictures', gl has at least 'textures', etc.. and usually this compositing can be done with some 'transform' (scaling, rotating, shearing,..) being specified. Most of the hardware accelerated aspects that evas needs really come from this compositing step. So what one can do is to realize one's object to an (argb buf, a8 buf), and 'put' this (plus maybe the global context color) on an engine provided buffer of some sort. Then let the engine do the compositing of this to the target surface. One can cache such buffers and only need re-generating/ putting the data from the obj when state changes require it.. and thus obtain some good performance on that part - even though you know nothing about what the object may be doing to realize itself onto the argb/a8 buffers that it puts on engine provided buffers. This would be really a must. As I am currently playing with some sdl engine, I see quite a lot of redundant code that could really benefit from some kind of surface allocator/destructor. Perhaps a first step would be to add this function to the current engine design. Some tests I've run show that even when the engine supports functions for drawing things like sub-pixel positioned polygons, it's actually faster to draw these in software and use the above. When I say faster here, I mean not 10% or 30% faster.. I mean it's like 20 or more times faster. This would be true on PC, but on embedded device you will really like the idea of using as much as possible the hardware. Preserving evas ability in this area is really something important in my opinion. But the main reason for this re-design is really to allow for both modular engines AND modular objects to work.. not just to make it easier to add new engines supporting the current set (or an extended set) of objects and/or their properties - though that is certainly an added bonus. Each object type is thus a collection of modules, one for each engine it may want to provide an optimized implementation for.. But it must provide at least one module - the 'generic' one. The mechanism is then setup so that this generic module can work with ANY engine - so long as the engine provides the required buffer functions, and its general gfx context 'derives' from the 'generic' one. This sound really good. Did you already start some work ? After playing a bit with evas engine, a lot of what you propose make sense and would really like to help in this area if I can. Cedric - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Cedric writes: Many engines have some sort of native notion of a 'buffer' that one can get/put data to, which they can composite to a target surface.. eg. xrender has 'pictures', gl has at least 'textures', etc.. and usually this compositing can be done with some 'transform' (scaling, rotating, shearing,..) being specified. Most of the hardware accelerated aspects that evas needs really come from this compositing step. So what one can do is to realize one's object to an (argb buf, a8 buf), and 'put' this (plus maybe the global context color) on an engine provided buffer of some sort. Then let the engine do the compositing of this to the target surface. One can cache such buffers and only need re- generating/putting the data from the obj when state changes require it.. and thus obtain some good performance on that part - even though you know nothing about what the object may be doing to realize itself onto the argb/a8 buffers that it puts on engine provided buffers. This would be really a must. As I am currently playing with some sdl engine, I see quite a lot of redundant code that could really benefit from some kind of surface allocator/destructor. Perhaps a first step would be to add this function to the current engine design. Some tests I've run show that even when the engine supports functions for drawing things like sub-pixel positioned polygons, it's actually faster to draw these in software and use the above. When I say faster here, I mean not 10% or 30% faster.. I mean it's like 20 or more times faster. This would be true on PC, but on embedded device you will really like the idea of using as much as possible the hardware. Preserving evas ability in this area is really something important in my opinion. Evas would do whatever the writer of the object type wants, for that given engine target.. if you want to have the fuzzy object implemented in the wombat engine this or that way, then that's what you'd do. For things like 'path' based object types, even if the target engine natively supports stroking and/or filling paths with textures etc. one may still want to optionally cache the results of such to engine-native buffers for redraws.. or not.. or even provide an option to enable that.. The generic version can't assume anything about the target engine, so it must draw things via software.. and wether or not to cache rendered results or not.. Well, that depends on quite a few things. But the main reason for this re-design is really to allow for both modular engines AND modular objects to work.. not just to make it easier to add new engines supporting the current set (or an extended set) of objects and/or their properties - though that is certainly an added bonus. Each object type is thus a collection of modules, one for each engine it may want to provide an optimized implementation for.. But it must provide at least one module - the 'generic' one. The mechanism is then setup so that this generic module can work with ANY engine - so long as the engine provides the required buffer functions, and its general gfx context 'derives' from the 'generic' one. This sound really good. Did you already start some work ? After playing a bit with evas engine, a lot of what you propose make sense and would really like to help in this area if I can. I have some and I'm missing some.. nor had I settled on the exact set of buffer related engine funcs.. signatures/semantics, etc. The object types themselves need some things, etc. I thought about getting back to this some time in the future, but if you and maybe Jorge ar willing to give this a try, then it may be better to go ahead and try and finish it off now -- it would be very useful in many other ways as well, especially since much of the image rendering pipeline needs to be redone in order to get image fill rotation to happen. 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. 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. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list
Re: [E-devel] Evas Evoak future changes
On 8/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jorge writes: So, the gfx parts of the engines (and some that are not directly gfx aspects) are really mostly a bunch of functions that apply to each object type, and some core functions that apply to all object types, and some that apply to display-target aspects. So, the 'engines' are in large part just the obj types themselves. Extending the engines is thus largely equivalent to extending the set of object types, and possibly the global gfx context. If one can suitably set that up, then there's no need to export a lot of specific internals to get modularization. im not sure i actually understand what you are trying to explain :) maybe you mean that if i setup correctly an API for object engines there's no need to export internal functions? you are correct, and then is my fault to no explain myself correctly =) on the mail i sent there two different things: - make an object engine - export internal functions (note that the last isnt needed for the first) i'll explain a little more on what i did with my local version: in current evas each engine should declare a Evas_Func and fill the functions (this is the engine API). so the idea is to make another type of engine with its own type of functions struct, like Evas_Engine_Object_Func and make current struct like Evas_Engine_Render_Func. note that the comparision if the engine is of type render or object is done at the evas_engine subsystem i explained on the previous email. the type of functions an object engine should declare in its struct are for example a function for an object_move, object_resize, etc. there's no point that a normal engine (render) must define those functions too. so if i understood correctly this is the engine API which i already implemented in my local version. I see.. a bit.. :) I think it would be great for evas to have the 'object engine' aspect you developed.. though it's just never truly clear what object related functions are needed on a per object type basis. If you can have it without exporting the 'engine funcs' then that would be best I think (however, if this 'object engine' relates to exporting functions related to the canvas level object functions then see below). Exporting anything to do with the 'render engine' (the current engine funcs) would be premature, and in fact, I personally would like to get rid of most of the engine funcs - replaced by 'obj types'. Let me give you a better idea of what I have in mind here in case you find it of interest or relevant somehow.. it does seem like there's some overlap between what you describe as an obj-engine and some things I believe the render part of the engines could be modified to. Currently, if you wanted to add a new type of object to evas, then at the canvas level you need to add the set of api functions and the set of internal obj-funcs. At the engines level, you might have to add some set of engine functions for dealing with the states available through the obj's api, and possibly a render function. One way to achieve all this in a simple manner is to add engine functions which not only mirror the obj's api funcs, but also funcs which mirror the obj-funcs which all canvas objs may/need define ie. things like new, free, render, render-pre, is-visible,... If we do this for all objs, then the engine funcs relating to particular obj types can instead be considered as funcs belonging to an 'obj-type' structure associated with that type of obj. The set of such obj-types would thus become what is now the engine funcs.. They would no longer be held by an evas instance, but rather by an instance of the object-type relative to the given evas instance. Some of the funcs can be display-target specific (for more efficient implementations) - but there's a way to actually have a generic, or virtual, argb target (similar to the buffer engine) from which one could obtain any other targets.. IF the display targets support certain 'standard' functionality, namely: 1. the ability to 'grab' a selected part of the target surafce to an argb buffer, and to 'put' an argb buffer onto the target surface. 2. the ability to composite an argb buffer and an a8 mask onto the target surface. These two things, and some similar others, are what I would have as part of the engine funcs.. instead of the obj specific stuff. With just those two - you can go far.. albeit not necessarily the most efficient means of realizing an object type in a given display target, but a general fallback mechanism at least (that can be optimized per engine as desired later) - and one which would allow you to do things like add brand new display targets that work with object types it knows nothing about. If one sets things up as 'object
Re: [E-devel] Evas Evoak future changes
Jorge writes: So, the gfx parts of the engines (and some that are not directly gfx aspects) are really mostly a bunch of functions that apply to each object type, and some core functions that apply to all object types, and some that apply to display-target aspects. So, the 'engines' are in large part just the obj types themselves. Extending the engines is thus largely equivalent to extending the set of object types, and possibly the global gfx context. If one can suitably set that up, then there's no need to export a lot of specific internals to get modularization. im not sure i actually understand what you are trying to explain :) maybe you mean that if i setup correctly an API for object engines there's no need to export internal functions? you are correct, and then is my fault to no explain myself correctly =) on the mail i sent there two different things: - make an object engine - export internal functions (note that the last isnt needed for the first) i'll explain a little more on what i did with my local version: in current evas each engine should declare a Evas_Func and fill the functions (this is the engine API). so the idea is to make another type of engine with its own type of functions struct, like Evas_Engine_Object_Func and make current struct like Evas_Engine_Render_Func. note that the comparision if the engine is of type render or object is done at the evas_engine subsystem i explained on the previous email. the type of functions an object engine should declare in its struct are for example a function for an object_move, object_resize, etc. there's no point that a normal engine (render) must define those functions too. so if i understood correctly this is the engine API which i already implemented in my local version. I see.. a bit.. :) I think it would be great for evas to have the 'object engine' aspect you developed.. though it's just never truly clear what object related functions are needed on a per object type basis. If you can have it without exporting the 'engine funcs' then that would be best I think (however, if this 'object engine' relates to exporting functions related to the canvas level object functions then see below). Exporting anything to do with the 'render engine' (the current engine funcs) would be premature, and in fact, I personally would like to get rid of most of the engine funcs - replaced by 'obj types'. Let me give you a better idea of what I have in mind here in case you find it of interest or relevant somehow.. it does seem like there's some overlap between what you describe as an obj-engine and some things I believe the render part of the engines could be modified to. Currently, if you wanted to add a new type of object to evas, then at the canvas level you need to add the set of api functions and the set of internal obj-funcs. At the engines level, you might have to add some set of engine functions for dealing with the states available through the obj's api, and possibly a render function. One way to achieve all this in a simple manner is to add engine functions which not only mirror the obj's api funcs, but also funcs which mirror the obj-funcs which all canvas objs may/need define ie. things like new, free, render, render-pre, is-visible,... If we do this for all objs, then the engine funcs relating to particular obj types can instead be considered as funcs belonging to an 'obj-type' structure associated with that type of obj. The set of such obj-types would thus become what is now the engine funcs.. They would no longer be held by an evas instance, but rather by an instance of the object-type relative to the given evas instance. Some of the funcs can be display-target specific (for more efficient implementations) - but there's a way to actually have a generic, or virtual, argb target (similar to the buffer engine) from which one could obtain any other targets.. IF the display targets support certain 'standard' functionality, namely: 1. the ability to 'grab' a selected part of the target surafce to an argb buffer, and to 'put' an argb buffer onto the target surface. 2. the ability to composite an argb buffer and an a8 mask onto the target surface. These two things, and some similar others, are what I would have as part of the engine funcs.. instead of the obj specific stuff. With just those two - you can go far.. albeit not necessarily the most efficient means of realizing an object type in a given display target, but a general fallback mechanism at least (that can be optimized per engine as desired later) - and one which would allow you to do things like add brand new display targets that work with object types it knows nothing about. If one sets things up as 'object types', rather than 'engine funcs', plus some 'standard' funcs related to argb buffers... then not much is needed to be shared beyond
Re: [E-devel] Evas Evoak future changes
On 8/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jorge writes: snip But to export evas' internal structures, especially the engine funcs and such.. is really dangerous at this point in time, unless you're willing to freeze evas' capabilities, or just use this as a starting point and change things as one goes along until one is satisfied. you are right, if evas exports its internal function not only a change on the API would mean a version bump, but also a change on the internal functions/data structs. So, the gfx parts of the engines (and some that are not directly gfx aspects) are really mostly a bunch of functions that apply to each object type, and some core functions that apply to all object types, and some that apply to display-target aspects. So, the 'engines' are in large part just the obj types themselves. Extending the engines is thus largely equivalent to extending the set of object types, and possibly the global gfx context. If one can suitably set that up, then there's no need to export a lot of specific internals to get modularization. im not sure i actually understand what you are trying to explain :) maybe you mean that if i setup correctly an API for object engines there's no need to export internal functions? you are correct, and then is my fault to no explain myself correctly =) on the mail i sent there two different things: - make an object engine - export internal functions (note that the last isnt needed for the first) i'll explain a little more on what i did with my local version: in current evas each engine should declare a Evas_Func and fill the functions (this is the engine API). so the idea is to make another type of engine with its own type of functions struct, like Evas_Engine_Object_Func and make current struct like Evas_Engine_Render_Func. note that the comparision if the engine is of type render or object is done at the evas_engine subsystem i explained on the previous email. the type of functions an object engine should declare in its struct are for example a function for an object_move, object_resize, etc. there's no point that a normal engine (render) must define those functions too. so if i understood correctly this is the engine API which i already implemented in my local version. about the internal headers thing, is to actually have the possibility to use evas internal functions on modules out of the main source tree, not only engines, but loaders, savers, even objects. dont know if this is clearer or it isnt even the answer you were expecting =) regards, jorge. Again, I'm not sure what I could tell you right now except that it's great stuff and dangerous stuff at the same time.. :) 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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Jorge writes: 1. reorder the headers: every subsystem has its own header, no more one huge header (Evas.h, evas_private.h, evas_common.h). as the main idea of this is to allow objects, loaders/savers, engines to be able to build outside evas, we need a way to export internal API. So for example there will exist beside evas_callbacks.c an evas_callbacks.h, etc. 2. support for internal, api headers (Evas.h, Evas_Internal.h) the way of how the evas apps current include evas headers must not change. so the normal apps will still include Evas.h using the evas-config --cflags, there's no change there. but now the content of Evas.h is some kind of superheader including the subsystems headers or some generic typedef in case of the api (to keep the data structs private) ... ... Another possibility, instead of this superheader thing, is that in the case of third party module, there could be a preprocessor define like -DEVAS_DEV to include all the private structs. ... ... the concept is similar to the linux kernel. talked to raster about this, and he doesnt like the idea too much, but in my opinion is cleaner but a bit more complicated, than having a evas_private.h with all the private data types there. 3. support for remote engines or object engines (havent decided the name yet, on my tree is REMOTE_ENGINE/RENDER_ENGINE), think is best to call it OBJECT_ENGINE. what does it does? its just layer above the obejcts interface, whenever a object_* function is called also the remote engine functions get called, this will allow evoak to work nicely (as it currently works here). 4. creation of evas_engine: this will be an interface between evas and its rendering/remote engine.imho the evas-engine.func-foo() approach isnt good enough, better use just evas_engine_foo to keep it secure (i.e comparing against null) and to use a generic engine (software) in case that a render engine doesnt support a particular callback. so the inheritance stuff should be rewritten in some way, because the software engine will be already a fallback engine. 5. add an engine data to objects, for things like ids on objects from the engine side, better this way than having evas to handle ids for objects (autoincrement, initialize, etc). (todo...) 6. i think a good idea is to have some kind of prioritization for engines, having to update all the engines when some api change even if the engine is not used at all in any app, is pointless. so as evas in this state will allow engines to be built outside, i think is a good moment to move unused engines outside main evas tree. 7. support for the new engine api raster and jose have been talking about, dunno exactly what is the plan, would be a good idea to share that :) 8. make objects real modules. maybe include the pre-post render too? 9. anything else?? in the future would be nice to have evas data types in a common place instead of evas, to allow other non- graphics apps to use those. maybe merge them with Ecore_Data? i know currently there's a circular dependency (Ecore_Evas) but in the future would be a good idea. when points 1-5 are done, ill commit the new evoak code. just note that i wont be able to commit much things until mid of september, as im finishing the university (finally) and have no time at all. but we have a good time to discuss things, and implement in a good way. any comments about this ideas/plan or addition of new ones would be appreciated. bye! Oh man, I don't know what to tell you. It's great work, and many of the things you mention here would be very nice to have.. structuring of headers, public and private, so as to have a less monolithic system, ecore based data structures used in evas, and some others. But to export evas' internal structures, especially the engine funcs and such.. is really dangerous at this point in time, unless you're willing to freeze evas' capabilities, or just use this as a starting point and change things as one goes along until one is satisfied. I did some of this a while ago, and stopped when I realized just how much I was going to need to change in order to get things like obj clipping, stroke/fill aspects, rotation/shearing, etc. The thing is, there's no way to really know for certain exactly what you're going to need until you come close to actually implementing every aspect that you want.. I've come pretty close to getting done most things I want, but there are still some things left. The engines use a global gfx context that holds general gfx info about how to render things (color, clip, etc), and then on top of that, each obj may have specific info that it needs to render itself (eg. borders for images). Some of these can be made a global gfx context for that type, some may be needed on a per object instance. So, the gfx parts of the engines (and some that are not directly gfx aspects) are really
