> As you can see from CVS log, I did some repacking of Evas_Object and
> managed to save more than 80 bytes, almost 1/3 of it is gone.
>
> While some aggressive packing went in, like "layer" number being a
> short now, I'm a bit unsure if applying the attached patch is a good
> thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
> but the solution is a bit ugly, as the members
> cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
> can be packed with the other bitfields. On one hand it saves memory,
> on the other it's ugly as hell :-P
>
> Apply or not? that's the question...
>
> PS: please test Evas on as many
> machines/architectures/compilers/operating systems as possible to see
> nothing is broken by these patches! It relies on compilers working
> fine with bitfields.I'll try on windows with mingw. Indeed, i've forgotten to add -mms-bitfields in the compilation flags in the efl, which is needed if other programs use evas and are compiled with ms vc++ if i'm not mistaken. See: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00253.html There is a description of that flag Vincent PS: unit tests... ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
