On Tue, 18 Dec 2007 19:12:46 +0100 Cedric BAIL <[EMAIL PROTECTED]> babbled:
> Hi, > > I have been working on some little improvement for Edje recently. The > first patch, "edje_data_file.diff", add support for a data.file entry inside > edc file. It give the possibility to put text file inside edje directy. It hmm - ok. sounds ok to me - using that for copyrights and such? note - your patch has bugs. you snprintf the mmaped() data - which is not guaranteed to be 0 byte terminated. snprintf is going a bit far there. just a malloc() of the file size + 1, a read() into the malloced buffer and set the last byte of the buffer as 0 will do the job fine. :) > also provide EDJE_FILL_TYPE_TILE_WIDTH and EDJE_FILL_TYPE_TILE_HEIGHT for > fill.type, this give the possibility to scale in one direction, and repeat > tile in the other direction. This patch is small and will not impact existing > edje application. ummm.... that already is possible. set the fill.size.relative in one dimension to 0.0 and the other 1.0 then use fill.size.offset to define the tile size in pixels for the dimension u set to 0.0 and 0 for the one at 1.0. you should know the dimensions of your image at edje_cc time so getting the image size runtime is only a convenience. so the patch for this needs some fixing - the fill stuff imho is not needed. > I also provide a rerun of eet race condition patch. It should apply > correctly and it should not break any thing also. can you describe the race condition it fixes? about half the patch as i'm reading it is moving of code around and whitespace changes so i'm not able to really see what it fixes and how? > The last patch is a more complex patch and need carefull review. It > replace fnmatch by a edje specific match. We did it with a friend, Thomas > Claveirole, and it work like fnmatch. We did make it work like > edje_glob_match, it recognize [], ? and *. As it replace all fnmatch call > inside edje, it could break any existing edje applications, if we didn't > handle all case correctly. So if you have time, apply this patch to your CVS > and test all edje application you have (with and without the patch ofcourse). > This replacement of fnmatch should be more easy to port to other system and > it could be faster than the original fnmatch version. problem. you don't match '.' (single character). i.e. "blah.blah" would match "blahXblah" "blah-blah" "blahhblah" but not "blahblah". > A last topic I would like to discuss is FPU need by Edje. Right now > without hardware floatting point, Edje could loose around 30% of time in soft > float when you have many objects on the screen. I don't know what would be > the best solution to this problem, doing some fixed point calculation or > caching result, updating them when required. If people have idea on this I > would like to ear as it is something I want to fix. i think i'd want to see some real performance numbers here. i do know edje has a habit of over-calculating. it really does calculate a LOT. possibly much more than it should. any fp heaviness is probably not a result of fp math itself but just that edje calculates too much. we possibly should focus on reducing calculations in general first. one example would be to queue recalculations per object until you force a calc via edje_object_calc_force() or until idle time. that could remove a lot. min size calcs are also slow. we could cache this value for an object if nothing changed that would affect its size. moving some core of some calcs to be fixed point or pure integer could help too. most of the calcs FIRST promote TO floating point - then do it all in fp, then go back to integer at the end. but i'd do this as a final step in this fix list. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
