On Tue, 3 Dec 2019 10:03:55 +0800 (CST) Jing  <[email protected]> said:

> Hi Carsten,
> You can put these files into efl-1.21.1/src/examples/edje, and use below
> command to complile. edje_cc -beta edje-anchors.edc animations.edc ;
> gcc -o edje-anchors edje-anchors.c `pkg-config --libs --cflags evas ecore
> ecore-evas edje`

so this example leaks too you think? reading it... if you happen to press a  2
times in a row it'll leak because you will overwrite the g_viewObj variable
with a new object, losing the handle on the old one... i modified it by adding:

       if (g_viewObj) evas_object_del(g_viewObj);

in 

    if (!strcmp(ev->key, "a")) {}

so the old object is guaranteed to be deleted before losing its handle. i
cleaned up the formatting and the dirname/snprintf stuff that was not
necessarily always going to work if argv[0] didnt have a full or relative path
in it O(just referring to the file as ./edje-anchors.edj would do fine) and
removed some pointless casts (casting to/from void * doesn't need an explicit
cast in C)... I ended up with the attached source file and massif tells me this
when i hold down the a key for a while which adds and deletes:

http://www.enlightenment.org/ss/e-5de62650098be9.83426512.png

that's a pretty steady memory use. it grows a bit as things get loaded up,
llists gets filled and emptied and memory pools get filled up and allocated
(the memory pools exist to avoid more allocations going through libc since we
allocate many objects of the same size so we have our own pools we pull
allocations from).

i also remember to set the object handle to null after deletion with the "d" key
so pressing "d" twice doesn't end up with trying to delete an invalid object
handle... and of course pressing a twice in a row doesn't result in a leak now
too.

> I also attach the massif output file, please help to check,  many thanks.
> 
> At 2019-12-03 03:57:44, "Carsten Haitzler" <[email protected]> wrote:
> >On Mon, 2 Dec 2019 20:23:08 +0800 (CST) Jing  <[email protected]> said:
> >
> >> Hi Carsten,
> >> Please find attached efl demo,  i press key "a" to call
> >> edje_object_add(obj) and edje_object_file_set(obj, animations.edj,
> >> group),  and then press  key "d" to evas_object_del(obj), repeat press "a"
> >> and "b" several times,  use linux comman ps to show the memory , you can
> >> find that the memory keep growing as shown below.  These memory will not
> >> free until device reboot. Please help to advise, many thanks.
> >
> >can you send me a compileable demo app too? also ... have you tried valgrind
> >+ massif as i suggested?
> >
> >there is nothing in an edje file that should cause any leak. i suspect the
> >problem is somewhere else - (if there even is a leak) so... if you send that
> >i can look and see.
> >
> >> At 2019-12-02 19:05:00, "Carsten Haitzler" <[email protected]> wrote:
> >> >On Mon, 2 Dec 2019 16:11:32 +0800 (CST) Jing  <[email protected]> said:
> >> >
> >> >> Hi Carsten,
> >> >> Currently, when enter a layout , my program will  use edje_object_add()
> >> >> to add an object, and then use edje_object_file_set() to define the
> >> >> layout by EDC file, the object will saved into stack, when exit from
> >> >> the layout, then will use evas_object_del() to delete the object. A
> >> >> same layout, i enter and exit several times, the memory will keep
> >> >> growing. For example, the initial memory is A,
> >> >> 1.  After first time enter and exit, the memory will grow to B
> >> >> 2.  On the second try enter, the memory still B, but after exit, the
> >> >> memory will grow to C.  ---Why ?? Please help to advise how to fix this
> >> >> issue.
> >> >
> >> >It should not keep growing. I don't know why you see this. If you use
> >> >valgrind+massif and massif-visualizer you will be able to start finding
> >> >out what is growing. you need to force it to grow a lot to really see (so
> >> >just keep triggering the loop and making it leak until the leak is big).
> >> >
> >> >efl has lots of caching behind the scenes. we store lots of data in global
> >> >caches so to some extent memory can grow a bit (up to a limit) due to
> >> >this. it all depends on the situation.
> >> >
> >> >> Besides, I don't quite understand your below saying,  do you have demo
> >> >> for it ?   
> >> >
> >> >if you do what i described below in a for loop the evas objects will not
> >> >be deleted when evas_object_del is called. the deletion is delayed until
> >> >the whole mainloop has gone through a few cycles (evas has rendered at
> >> >least 2 or 3 frames of updates) THEN the objects get deleted. they are
> >> >queued a marked for deletion and will later be deleted... but it takes
> >> >some time and some rendering to do that. objects have to stay around for
> >> >a few render cycles due to evas having to calculate previous+current
> >> >update regions. the objects have to stay there so the difference can be
> >> >calculated. if an object is deleted when you call evas_object_del() then
> >> >there is no object to use to calculate the difference between previous
> >> >and current frame.
> >> >
> >> >> "your memory will keep growing ad the objects will be queued for
> >> >> deletion after 2 more renders. you would need the main loop to go idle
> >> >> *AND* for there to be visible changes in the canvas needing rendering.
> >> >> evas_norender(evas); exists for these cases where you do a loop where
> >> >> you add/del objects and never show them or have them rendered (and just
> >> >> use the canvas as a workbench). this forces a "no rendering" render
> >> >> cycle that will clean up queued objects.
> >> >> 
> >> >> it's exceedingly rare to do the above without having your canvas go
> >> >> through some rendering at some point.
> >> >> 
> >> >> also edje will QUEUE signals and process them in idle time. if there is
> >> >> never any idle time in the ecore mainloop then the signals will just
> >> >> queue up and not be processed. setting a file will produce some signals
> >> >> already (like "load" "")."
> >> >> 
> >> >> 
> >> >> At 2019-11-30 00:45:26, "Carsten Haitzler" <[email protected]> wrote:
> >> >> >On Fri, 29 Nov 2019 09:10:05 +0800 (CST) Jing  <[email protected]>
> >> >> >said:
> >> >> >
> >> >> >> OK, Carsten, please help to check my code flow, Is there anything
> >> >> >> wrong? Please advise, thanks.
> >> >> >
> >> >> >there is nothing wrong with it. hiding isn't needed as deletion already
> >> >> >hides... it might be smarter to show after you have moved and resized
> >> >> >and set layer to avoid extra events, but nothing really is wrong there.
> >> >> >
> >> >> >have you used valgrind and massif to crack memory usage, then
> >> >> >massif-visualizer to view it?
> >> >> >
> >> >> >> 在 2019-11-29 05:16:23,"Carsten Haitzler" <[email protected]> 写
> >> >> >> 道:
> >> >> >> >On Thu, 28 Nov 2019 20:14:53 +0800 (CST) Jing  <[email protected]>
> >> >> >> >said:
> >> >> >> >
> >> >> >> >> Thanks Carsten,
> >> >> >> >> 
> >> >> >> >> 
> >> >> >> >> I did not find edje_object_del(), did you mean evas_object_del()?
> >> >> >> >
> >> >> >> >sorry - my typo. evas_object_del();
> >> >> >> >
> >> >> >> >> Here is my code flow:
> >> >> >> >> //enter:
> >> >> >> >> obj = edje_object_add(evas)
> >> >> >> >> edje_object_file_set(obj, file , grup)
> >> >> >> >> evas_object_show(obj )
> >> >> >> >> evas_object_move()
> >> >> >> >> evas_object_resize()
> >> >> >> >> evas_object_focus_set()
> >> >> >> >> evas_object_layer_set()
> >> >> >> >> //exit:
> >> >> >> >> evas_object_hide(obj)
> >> >> >> >> evas_object_del(obj)
> >> >> >> >> Is there anything wrong? Please advise, thanks.
> >> >> >> >> 
> >> >> >> >> At 2019-11-28 17:21:38, "Carsten Haitzler (The Rasterman)"
> >> >> >> >> <[email protected]> wrote:
> >> >> >> >> >On Thu, 28 Nov 2019 15:43:17 +0800 (CST) Jing
> >> >> >> >> ><[email protected]> said:
> >> >> >> >> >
> >> >> >> >> >> Thanks Hermet for you reply.
> >> >> >> >> >> 
> >> >> >> >> >> 
> >> >> >> >> >> In my test, i find that if i call function
> >> >> >> >> >> edje_object_file_set(Edje_Object *obj, const char *file, const
> >> >> >> >> >> char *group), even i call evas_object_del(Edje_Object *obj); to
> >> >> >> >> >> delete the obj, the memory of my program will keep growing, if
> >> >> >> >> >> i am not use edje_object_file_set() then this issue will not
> >> >> >> >> >> exists.  Is there a way to free the memory of
> >> >> >> >> >> edje_object_file_set() ? Please advise, thanks.
> >> >> >> >> >
> >> >> >> >> >Memory will be freed... is it possible you are not getting any
> >> >> >> >> >rendering happening? e.g. if you do something like:
> >> >> >> >> >
> >> >> >> >> >for (i = 0; i < 100000; i++) {
> >> >> >> >> >  o = edje_object_add(evas);
> >> >> >> >> >  edje_object_del(o);
> >> >> >> >> >}
> >> >> >> >> >
> >> >> >> >> >your memory will keep growing ad the objects will be queued for
> >> >> >> >> >deletion after 2 more renders. you would need the main loop to go
> >> >> >> >> >idle *AND* for there to be visible changes in the canvas needing
> >> >> >> >> >rendering. evas_norender(evas); exists for these cases where you
> >> >> >> >> >do a loop where you add/del objects and never show them or have
> >> >> >> >> >them rendered (and just use the canvas as a workbench). this
> >> >> >> >> >forces a "no rendering" render cycle that will clean up queued
> >> >> >> >> >objects.
> >> >> >> >> >
> >> >> >> >> >it's exceedingly rare to do the above without having your canvas
> >> >> >> >> >go through some rendering at some point.
> >> >> >> >> >
> >> >> >> >> >also edje will QUEUE signals and process them in idle time. if
> >> >> >> >> >there is never any idle time in the ecore mainloop then the
> >> >> >> >> >signals will just queue up and not be processed. setting a file
> >> >> >> >> >will produce some signals already (like "load" "").
> >> >> >> >> >
> >> >> >> >> >> At 2019-11-26 12:24:45, "Hermet Park" <[email protected]>
> >> >> >> >> >> wrote:
> >> >> >> >> >> >Once object is deleted, the subsequent memory belonging to the
> >> >> >> >> >> >object will be removed as well.
> >> >> >> >> >> >You don't need to care about it. Callbacks neither.
> >> >> >> >> >> >
> >> >> >> >> >> >On Mon, Nov 25, 2019 at 9:12 PM Jing <[email protected]>
> >> >> >> >> >> >wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >> Hi all,
> >> >> >> >> >> >> I have some memory free questions when using below two
> >> >> >> >> >> >> functions:
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> 1.  EAPI Eina_Bool edje_object_file_set(Evas_Object *obj,
> >> >> >> >> >> >> const char *file, const char *group);
> >> >> >> >> >> >> ---  After this function done,  i will call  evas_object_del
> >> >> >> >> >> >> (obj) to delete the obj,  anything else that i need to
> >> >> >> >> >> >> free ? For example, the edj file used in this funciton?
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> 2.  evas_object_event_callback_add(Evas_Object *eo_obj,
> >> >> >> >> >> >> Evas_Callback_Type type, Evas_Object_Event_Cb func, const
> >> >> >> >> >> >> void *data)
> >> >> >> >> >> >> ---- After this function done,  i will call  evas_object_del
> >> >> >> >> >> >> (obj) to delete the obj,   the callback will be auto deleted
> >> >> >> >> >> >> after evas_object_del or  i have to use
> >> >> >> >> >> >> evas_object_event_callback_del(Evas_Object *eo_obj,
> >> >> >> >> >> >> Evas_Callback_Type type, Evas_Object_Event_Cb func) to
> >> >> >> >> >> >> delete ?
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Thanks.
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> >> >> [email protected]
> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >-- 
> >> >> >> >> >> >Regards, Hermet
> >> >> >> >> >> >
> >> >> >> >> >> >_______________________________________________
> >> >> >> >> >> >enlightenment-devel mailing list
> >> >> >> >> >> >[email protected]
> >> >> >> >> >> >https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> 
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> >> [email protected]
> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >> >> 
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >-- 
> >> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >> >-------------- Carsten Haitzler - [email protected]
> >> >> >> >> 
> >> >> >> >> _______________________________________________
> >> >> >> >> enlightenment-devel mailing list
> >> >> >> >> [email protected]
> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >> >
> >> >> >> >
> >> >> >> >-- 
> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >-------------- Carsten Haitzler - [email protected]
> >> >> >
> >> >> >
> >> >> >-- 
> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >-------------- Carsten Haitzler - [email protected]
> >> >> 
> >> >> _______________________________________________
> >> >> enlightenment-devel mailing list
> >> >> [email protected]
> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >
> >> >
> >> >-- 
> >> >------------- Codito, ergo sum - "I code, therefore I am" --------------
> >> >Carsten Haitzler - [email protected]
> >
> >
> >-- 
> >------------- Codito, ergo sum - "I code, therefore I am" --------------
> >Carsten Haitzler - [email protected]


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]

/**
 * Simple Edje example for layouting parts with anchors.
 *
 * You'll need at least one Evas engine built for it (excluding the
 * buffer one). See stdout/stderr for output.
 *
 * @verbatim
 * edje_cc edje-anchors.edc && gcc -o edje-anchors edje-anchors.c `pkg-config 
--libs --cflags evas ecore ecore-evas edje`
 * @endverbatim
 */

#ifdef HAVE_CONFIG_H
# include "config.h"
#else
# define EINA_UNUSED
#endif

#include <Ecore.h>
#include <Ecore_Evas.h>
#include <Edje.h>
#include <libgen.h>

#define WIDTH 400
#define HEIGHT 400

Evas_Object *g_viewObj = NULL;


static void
_on_key_down(void *data EINA_UNUSED, Evas *evas EINA_UNUSED, Evas_Object *obj, 
void *event_info)
{
   Evas_Event_Key_Down *ev = event_info;

   printf("key:%s\n", ev->key);
   if (!strcmp(ev->key, "a"))
    {
       if (g_viewObj) evas_object_del(g_viewObj);
       g_viewObj = edje_object_add((Evas *)data);
       edje_object_file_set(g_viewObj, "./animations.edj", "animations_group");
       evas_object_resize(g_viewObj, WIDTH, HEIGHT);
       evas_object_show(g_viewObj);
    }

   if (!strcmp(ev->key, "d"))
     {
        evas_object_del(g_viewObj);
        g_viewObj = NULL;
     }

   if (!strcmp(ev->key, "Escape"))
     ecore_main_loop_quit();
}


int
main(int argc EINA_UNUSED, char **argv)
{
   ecore_init();
   ecore_evas_init();
   edje_init();

   Ecore_Evas *ee = ecore_evas_new(NULL, 0, 0, WIDTH, HEIGHT, NULL);
   Evas *e = ecore_evas_get(ee);
   ecore_evas_show(ee);

   Evas_Object *bg = evas_object_rectangle_add(e);
   evas_object_color_set(bg, 64, 64, 64, 255);
   evas_object_resize(bg, WIDTH, HEIGHT);
   evas_object_show(bg);

   Evas_Object *edje = edje_object_add(e);
   edje_object_file_set(edje, "./edje-anchors.edj", "main");
   evas_object_resize(edje, WIDTH, HEIGHT);

   evas_object_event_callback_add(edje, EVAS_CALLBACK_KEY_DOWN,
                                  _on_key_down, e);
   evas_object_focus_set(edje, EINA_TRUE);
   evas_object_show(edje);

   ecore_main_loop_begin();

   edje_shutdown();
   ecore_evas_free(ee);
   ecore_evas_shutdown();
   ecore_shutdown();
   return 0;
}
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to