Gustavo wrote:
> Hi guys,
>
> 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...
>
Hey man, I hope you didn't think my remarks about adding
properties and such had to do with object sizes... It was more
about having all these things (including some older stuff) that
may or may not apply to this or that obj type, no way to know,
etc. Ideally a "pie in the sky" kind of thing would be an evas
based on an ecore_object 'object' system (with all the ecore gui
stuff, including ecore_evas, split off from an ecore base), and
similar utopian ideals. :)
Anyway... although I'm not sure just how 'important' it is
(in practice) to have object sizes cut down as much as you managed,
that's nice work anyhow! But yeah, some of it is a bit 'ugly'...
maybe leave those parts alone?
BTW, did you kill Kenny with all that chopping away?
-------------------------------------------------------------------------
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
