On Fri, 26 Aug 2016 22:14:11 -0700 Cedric BAIL said:
> On Fri, Aug 26, 2016 at 5:44 PM, Carsten Haitzler
> wrote:
> > On Fri, 26 Aug 2016 12:15:57 -0700 Cedric BAIL said:
> >> On Fri, Aug 26, 2016 at 2:46 AM, Tom Hacohen wrote:
> >> > On 24/08/16 20:03, Cedric BAIL wrote:
> >> >> On Wed, Aug 2
On Fri, Aug 26, 2016 at 5:44 PM, Carsten Haitzler wrote:
> On Fri, 26 Aug 2016 12:15:57 -0700 Cedric BAIL said:
>> On Fri, Aug 26, 2016 at 2:46 AM, Tom Hacohen wrote:
>> > On 24/08/16 20:03, Cedric BAIL wrote:
>> >> On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen wrote:
>> >>> On 23/08/16 18:51, C
On Fri, 26 Aug 2016 12:15:57 -0700 Cedric BAIL said:
> On Fri, Aug 26, 2016 at 2:46 AM, Tom Hacohen wrote:
> > On 24/08/16 20:03, Cedric BAIL wrote:
> >> On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen wrote:
> >>> On 23/08/16 18:51, Cedric BAIL wrote:
> On Tue, Aug 23, 2016 at 3:31 AM, Tom H
On Fri, Aug 26, 2016 at 2:46 AM, Tom Hacohen wrote:
> On 24/08/16 20:03, Cedric BAIL wrote:
>> On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen wrote:
>>> On 23/08/16 18:51, Cedric BAIL wrote:
On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
>>
>>
>>
> However, while they provide a nice
On 26/08/16 11:21, David Seikel wrote:
> On Fri, 26 Aug 2016 10:46:48 +0100 Tom Hacohen
> wrote:
>
>> a shitload of times. If I remember correctly, _efl_object_call_end is
>> one line: _eo_unref(obj). And that one is essentially if
>> (--(obj->ref) == 0) and then just returns in 99.99% of the case
On Fri, 26 Aug 2016 10:46:48 +0100 Tom Hacohen
wrote:
> a shitload of times. If I remember correctly, _efl_object_call_end is
> one line: _eo_unref(obj). And that one is essentially if
> (--(obj->ref) == 0) and then just returns in 99.99% of the cases. Not
> a lot to optimise there. :)
Make it a
On 24/08/16 20:03, Cedric BAIL wrote:
> On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen wrote:
>> On 23/08/16 18:51, Cedric BAIL wrote:
>>> On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
>
>
>
However, while they provide a nice memory improvement, they have been
hampering many optimi
On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen wrote:
> On 23/08/16 18:51, Cedric BAIL wrote:
>> On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
>>> However, while they provide a nice memory improvement, they have been
>>> hampering many optimisation strategies that would make callback
>>> i
On 23/08/16 18:51, Cedric BAIL wrote:
> Hello,
>
> On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
>> Callback arrays was an idea that was introduced a while back to save
>> memory. The idea came from the observation that in many cases we add a
>> few callbacks together to every object of the
On Tue, 23 Aug 2016 10:51:05 -0700 Cedric BAIL said:
> Hello,
>
> On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
> > Callback arrays was an idea that was introduced a while back to save
> > memory. The idea came from the observation that in many cases we add a
> > few callbacks together to
Hello,
On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen wrote:
> Callback arrays was an idea that was introduced a while back to save
> memory. The idea came from the observation that in many cases we add a
> few callbacks together to every object of the same type. For example,
> for an elm widget, w
Hi
On 08/23/2016 03:59 PM, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 23, 2016 at 7:31 AM, Tom Hacohen wrote:
>>
>> Hey,
>>
>> Callback arrays was an idea that was introduced a while back to save
>> memory.
>
> ohhh, I guessed it was to improve usability, saving many "add" calls
> at the end
On Tue, Aug 23, 2016 at 7:31 AM, Tom Hacohen wrote:
>
> Hey,
>
> Callback arrays was an idea that was introduced a while back to save
> memory.
ohhh, I guessed it was to improve usability, saving many "add" calls
at the end of an "eo_add()"... at least it's how I use them.
Take a look in GIT to
Hey,
Callback arrays was an idea that was introduced a while back to save
memory. The idea came from the observation that in many cases we add a
few callbacks together to every object of the same type. For example,
for an elm widget, we may add "move, resize, hidden, mouse_down,
mouse_up" so
On Tue, 22 Jan 2013 18:57:36 +0900 Cedric BAIL said:
> Hello,
>
>I have been chasing source of memory consumption in EFL since a few
> weeks now. There is one source that I didn't hunt yet, callbacks. In
> some small elementary_test they easily get over 400KB of
> Evas_Func_Node. This func n
On Tue, 22 Jan 2013 11:21:08 -0200 Gustavo Sverzut Barbieri
said:
> On Tue, Jan 22, 2013 at 7:57 AM, Cedric BAIL wrote:
> > Hello,
> >
> >I have been chasing source of memory consumption in EFL since a few
> > weeks now. There is one source that I didn't hunt yet, callbacks. In
> > some smal
On Wed, Jan 23, 2013 at 1:27 AM, Tom Hacohen wrote:
> On 22/01/13 13:21, Gustavo Sverzut Barbieri wrote:
>> On Tue, Jan 22, 2013 at 7:57 AM, Cedric BAIL wrote:
>>> Hello,
>>>
>>> I have been chasing source of memory consumption in EFL since a few
>>> weeks now. There is one source that I didn
On 22/01/13 13:21, Gustavo Sverzut Barbieri wrote:
> On Tue, Jan 22, 2013 at 7:57 AM, Cedric BAIL wrote:
>> Hello,
>>
>> I have been chasing source of memory consumption in EFL since a few
>> weeks now. There is one source that I didn't hunt yet, callbacks. In
>> some small elementary_test the
Hi,
On Tuesday, January 22, 2013, Leandro Pereira wrote:
> On 01/22/2013 11:21 AM, Gustavo Sverzut Barbieri wrote:
> > right now we use 4 pointers per node (prev, next, cb, data), plus some
> > information that due alignment should take an extra pointer-size
> > (type, priority, delete_me). So 5
On 01/22/2013 11:21 AM, Gustavo Sverzut Barbieri wrote:
> right now we use 4 pointers per node (prev, next, cb, data), plus some
> information that due alignment should take an extra pointer-size
> (type, priority, delete_me). So 5 pointer-size at least, but on my
> machine (32 bits) it's 28 bytes
On Tue, Jan 22, 2013 at 7:57 AM, Cedric BAIL wrote:
> Hello,
>
>I have been chasing source of memory consumption in EFL since a few
> weeks now. There is one source that I didn't hunt yet, callbacks. In
> some small elementary_test they easily get over 400KB of
> Evas_Func_Node. This func node
Hello,
I have been chasing source of memory consumption in EFL since a few
weeks now. There is one source that I didn't hunt yet, callbacks. In
some small elementary_test they easily get over 400KB of
Evas_Func_Node. This func node are not that big, but they are still a
list with a function poi
I'm no expert, but...(disclaimer)
the callback is raised when the mouse is moving over the zozor because
thats the object you have set the callback on.
if you had a transparent object (the size of your window) above
everything, and had the callback attached to that it would work as you
intend.
o
Hello and thanks
I have rename my topic on callback .
this topic follow the focus problem
i have update my code, and i have the minimum, so a background
"object_01" and on object zozor and i want this object follow the move
of the mouse.
and with this code the zozor will be follow the mouse only
On Mon, 23 Apr 2007 10:27:15 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:
> Hello,
>
> I'm writing python bindings and I noticed that there is now way to get
> notified when evas_free() is issued, this is a problem since this
> function can be called from my application, but from
Hello,
I'm writing python bindings and I noticed that there is now way to get
notified when evas_free() is issued, this is a problem since this
function can be called from my application, but from other libraries,
like ecore_evas.
I'd like to know if it's ok to provide a callback that would be ca
26 matches
Mail list logo
