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(). I also think that _evas_array_append() and _evas_array_get() should not be prefixed with "_". -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
