Hello everyone on the list, I'm a part-time developer who's got no "particular" skills but like to look around at different free/open source projects and get my hands on code. I started looking at evas and the EFL cause I found the idea of graphic canvas very clever, and I tought I could base some of my (no yet realized) projects on it. So I began by compiling and testing it, and some ideas came to my mind, that became some of my (currently worked on) projects.
The first one, that is now a bit on stand by, is python bindings for the EFL (or, for the begining, for evas only). I know that some already exist on the net (like the benko (http://www.benko.sk/benko/evas) one), but they're all written directly in C, without adapted tools; this is cool when you just have a handsome of functions, but it becomes a nightmare when you've got all a library to maintain (especially when some of the prototypes or functions role change only a bit and that you've got to search thru all the code to see if it's still correct). Look at those bindings, they're really big (in terms of number of lines) compared to what they can do (well, that's amazing to drive the evas from python, but what looks amazing is mainly the work from the evas...). And still, they're coded toward an old version of evas (without ecore_evas). So I began to do bindings with the help of SWIG (http://www.swig.org/), a tool which can do a lot for you, as bindings are generally a repetitive task. In only a few hundreds lines of code (well, about 1000 after some 'wc -l' on it), I did bindings for ecore, evas and ecore_evas (not complete ones, but as least as much as the other bindings). And those aren't unreadable lines of repetitive C code; they moslty are copy/paste of headers files, a bit modified to suit SWIG, and to be more object oriented. Well, this sounds good, but as I said at the begining, this projet is on stand by now, because of problems I encoutered while working on it: SWIG is cool when you stick to it's vision of bindings, but when you have a code that is quite object oriented (as evas is) and written in C, it's sometime difficult to solve some problems. So I patched SWIG, to get what I wanted (having class names different from the prefix of the functions related to them); I also used some tricks to get the same looking structures (the Evas_Event_* ones) not being repetead all the way, which became a really ugly trick; then I couldn't solve the problem of not finding back customized objects passed by callbacks (as objects are recontructed every time a C functions get them); then the problem of the user data for callbacks (well, lot of problems come from callbacks), which functions get which user data, etc... Finally, SWIG is a really big piece of code (implementig it's own vision of OO programming in C, like lot of projects, including evas; that's sometime really a pain for external developers), it's quite hard to modify (my 5 lines patch to SWIG took me hours), and its contributors are rather working on the C++ bindings than on the C ones, so I don't think I could go any further with it. Or maybe someone else... So I had the idea of looking at pygtk, the python bindings for GTK, which I used during my coding hours. It's based on GTK, a C library that is very object oriented, and has its own tools to generate its bindings: a set of python scripts (well, I like python a lot if you didn't get it), that can generate bindings directly from C headers, as long as you cutomize these scripts for you before (and that's the biggest part as you may have guessed). This permits a lot of freedom in your way of designing your bindings, but consequently you've got to code quite more lines. But at the end, it's as easy to maintain as SWIG-like bindings. Sounds good too, but there's still a lot of work to do : as GTK has it's own view of OO programming in C (yes, another different one), these tools have to be adapted to evas. And I didn't get very in touch with it for now, and is not in the top of my priority list for now, as I got bored of working on it. So after that long talk on python and evas, let's talk about my second projet: altivec optimizations for evas. I recently got a G4 IBook and wanted to test evas on it; after some compiling problems, I get it to run and ... well, that's not bad but I was once more disapointed by its result (the 800MHz G4 that's in this computer doesn't seem to be very powerfull, be warned...). Well, the OpenGL version of the evas test program run far better (thanks to the radeon 9200), but I wanted for long to study a bit the altivec instruction set; I had found my guinea-pig. So, inspired by the mmx functions, I began to code some functions using altivec, while learning thanks to the Apple's tutorials. I first looked at the top 5 that gave me gprof on the evas_software_x11_test, and I got quite good results for me, to give just a few: a 60% gain in blending pixels on pixels, and 33% gain in copying pixels (I also made an altivec optimized version for blending colors and colors with alpha). For now they're not perfect, and surely need some corrections and enhancement, but I think I could soon send them to this list... I've got one little thing to say about blending, as the the precision concern was discussed on this list (about the division by 255): the mmx version doesn't give at all the same result as the C one ("not at all" doesn't mean they're totally different, but lots of results are off by 1), and neither does my altivec version. So maybe a common algorithm should be decided to avoid the effects that could arise when lots of partially transparent layers get stacked (I didn't test it but it would be a good visual accuracy test); I read in the evas manual that the software renderer was the reference for all the engines about rendering quality. If the software engine gives differents results depending on the optimization activated... But I know that algorithms for SIMD may be very different from classical one, so I can't find a good solution. They're still some problems that make me not very happy with this altivec version; these aren't related to the altivec optimizations, but with Darwin, I think (oh, I forgot to mention that I'm working on MacOSX, not Linux for PPC; but these optimizations should work on it as well as they're not using Apple's library but gcc pseudo C routines that produce altivec assembly code). The first problem is the memory consumption: I know that evas doesn't leak memory, I tested every Apple's tool to look at memory leaks, and I didn't find anythink, but the evas test app is *filling up all the memory* !!! Not even 10s after having started it, the system begin to swap and evas slows down, lags, call it as you like but it doesn't run at a decent speed anymore. The only thing that made me realize it's really a memory problem is the System Monitor, that show evas test app's memory increasing and filling up all the RAM. I don't know where this bug comes from, but if someone has a clue on it, please help me track this problem down; it's really a big problem for the PPC port. The second one, is that in the top of the gprof results (i.e. the most time consuming functions), apart from the malloc/free routines that come here because of the 1st problem I described, are functions related to the X Window display. On MacOSX, X runs on top of Quartz, Apple's graphical engine, and I think this slows all the thing down a bit. Well, evas' test app is very graphic intensive, at least for the first part, and maybe that's why X drawing routines come first, but this may be a problem when the others will be solved. If someone has a linux ppc comp to test this on, and could tell me if these problems arise on a native X display, it would be great (I plan to install linux one day on mine, but for now it's quite in early stage of developement, even if it already works on most of the recent G4s). Well, that should be all I had to tell you, evas developers; I'd be happy to get advices if someone is working on one of these topics and wants to help. I thanks you all for the great work, espacially the Rasterman for giving birth to this wonderfull project! I forgot one thing: I've got no "direct" access to the net, so the CVS version I'm working on dates from about 6 months ago (well, it was from the SPLIT branch, but still..). I'll try to get up to date, before sending the patches, hoping that everything didn't change... benoar P.S.: And sorry for my english ... ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
