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] _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
