On Tue, Apr 15, 2008 at 4:22 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 6:03 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 14, 2008 at 7:51 PM, Gustavo Sverzut Barbieri > > <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 14, 2008 at 12:38 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > > > On Mon, Apr 14, 2008 at 11:55 AM, Cedric BAIL <[EMAIL PROTECTED]> > wrote: > > > > > On Sun, Apr 13, 2008 at 9:52 PM, Gustavo Sverzut Barbieri > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL <[EMAIL > PROTECTED]> wrote: > > > > > > > On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL <[EMAIL > PROTECTED]> wrote: > > > > > > - evas_array seems very useful, make it available to evas as > a > > > > > > whole! Just have it to take "void *" and it will do just > fine. Also, > > > > > > I'd make the increase amount (16) configurable after the > array is > > > > > > created (or provide an alternative constructor). > > > > > > > > > > Good idea, but as this are small functions and some are used a > lot I > > > > > like the idea of seeing them inlined. As there are more of this > kind > > > > > of function in Evas, small functions used a lot, I did move them > after > > > > > some profiling inside src/lib/include/evas_inline.x. This give > us a > > > > > little bit of speedup with only a small increase in library > size. The > > > > > function that could be inlined are : > > > > > - evas_object_is_opaque > > > > > - evas_event_passes_through > > > > > - evas_object_is_visible > > > > > - evas_object_clippers_is_visible > > > > > - evas_object_is_in_output_rect > > > > > - evas_object_is_active > > > > > - evas_object_coords_recalc > > > > > - evas_object_clip_recalc > > > > > > > > > > Are people interested by this kind of patch ? I would add > > > > > evas_object_array_push to this list also. > > > > > > > > Because code is better than discussion, here is a patch that does > > > > exactly that. Comment are welcome :-) > > > > > I like it. It could be dangerous for externally used calls, but for > > > those exported in evas_private.h, it makes sense. > > > > Right now, none of this function are exported to the outside. > > > > > > > I just think that some functions should be split in 2 parts: common > > > and corner, just the common part should be inline, while the corner, > > > usually bigger, should be regular function defined in evas_private.h. > > > This would avoid code growing too much while giving us the fast common > > > path. For example: evas_array_push will not have to realloc most of > > > times, so it should be in another function: > > > > I like this idea. So next patch with it :-) > > > > > > > Also, for _internal_ things I really dislike null-pointer checking: we > > > should never have one, if we do then we are buggy and must crash ASAP > > > to catch the error sooner. Just entry-point should do these checks to > > > make library robust. > > > > I like the idea of checking NULL pointer often, perhaps it will be > > better if I do it with assert so we can easily remove this test. > > > > So here is a implementation of Evas_Array on top of previous inline patch. > > Hum, step is not what I imagined, you should use it instead of "16" in > _evas_array_grow(), while using it in _evas_array_append().
Oops, this is a mistake. > I also think that _evas_array_append() and _evas_array_get() should > not be prefixed with "_". I prefixed them, because I provide an inlined version for Evas internal use (the one with "_") and an exported version as I don't want to export inlined version. -- Cedric BAIL ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
