Re: [E-devel] Evas memory consumption with async render.

2013-01-08 Thread Gustavo Sverzut Barbieri
On Tue, Jan 8, 2013 at 12:59 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: first... i ran a valgrind run overnight... hooray! the witch is dead.. errr. i mean the leak is gone. awesome!

[E-devel] Evas memory consumption with async render.

2013-01-07 Thread Gustavo Sverzut Barbieri
Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Tom Hacohen
I'm not sure there's a need for a specific row_draw, I think using the regular font_draw (with possible adjustments for fake-monospace) should be enough. On Mon, Jan 7, 2013 at 7:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Gustavo Sverzut Barbieri
On Mon, Jan 7, 2013 at 5:50 PM, Tom Hacohen t...@stosb.com wrote: I'm not sure there's a need for a specific row_draw, I think using the regular font_draw (with possible adjustments for fake-monospace) should be enough. It's not, and it will be a super waste as this will apply cutouts and

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Tom Hacohen
Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this logic on it's own, why would it need an engine to merge rects? This way textgrid will be able to do it for more than just one row... As for text: the current

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Gustavo Sverzut Barbieri
On Mon, Jan 7, 2013 at 6:47 PM, Tom Hacohen t...@stosb.com wrote: Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this logic on it's own, why would it need an engine to merge rects? This way textgrid will be

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread David Seikel
On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back:

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Ulisses Furquim
Hi David, On Mon, Jan 7, 2013 at 8:31 PM, David Seikel onef...@gmail.com wrote: On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see,

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread thomasg
On Mon, Jan 7, 2013 at 8:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back:

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread Cedric BAIL
On Tue, Jan 8, 2013 at 6:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 7, 2013 at 6:47 PM, Tom Hacohen t...@stosb.com wrote: Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this

Re: [E-devel] Evas memory consumption with async render.

2013-01-07 Thread The Rasterman
On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: first... i ran a valgrind run overnight... hooray! the witch is dead.. errr. i mean the leak is gone. awesome! http://www.enlightenment.org/ss/e-50eb86c540c731.34017080.png so no leak there. lot of big