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

[Gustavo S. B. <bar...@pr...>]

On Tue, Jan 8, 2013 at 12:59 AM, Carsten Haitzler <ra...@ra...>wrote:

> On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri
> <bar...@pr...> 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 peaks, but no leak. good!
>
> but that brings us to the topic of your mail... the peaks.. and they are
> really big compared to the baseline and that is a concern. mine seems
> nastier
> (6m->29m) that yours...
>

indeed, it will depend on how many chars it issued. As I said it will queue
one font draw command per cell :-(

this is fixable, but there are characteristics that will keep doing that.
For instance we apply cutouts in the main thread, and this produces one
thread command per remaining region. In a nasty case if you produce lots of
1x1 regions it will generate that many "useless" commands. The way to fix
this would include touching every place where cutout rects is used and it
would be way more error prone, almost impossible to get right (and
optimizations to reuse cutout rects would be even harder!)



> > 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 not showing any
> > abnormal behavior either, this is with EFL SVN (single tree).
>
> confirmed. :)
>
> > What we found is that textgrid implementation will have to change. Right
> > now it's very below what it should be, and for every cell it will issue 3
> > commands: one rectangle_draw() for BG, one font_draw() and one
>
> hmm not for rect. it will merge rects within a row. so a row with all the
> same
> colored bg will draw a single rect as the bg (for that row). see
> evas_object_textgrid_render() the if (!run)... it starts a new rect, if it
> detects a run of the same colored rect.. (c->r/g/b match rr./gg/bb) it
> expands
> the rect width, if color changes... it begins a new rect run. :) so from
> that
> pov i think we're good.
>

Ok, I did not read the code more than 20 minutes and did not notice this
was done already.


sure - underline and strikethrough dont get merged. there's an XXX: for
> that -
> i just found them to be so rare, that i didn't bother. :) indeed merging
> these
> into a run would be good too...
>
> the issue at hand really is the text. yes. it issues a text draw PER char
> it
> draws in a row (of course empty cells get no draw call).
>

ok, then if you think this could be simplified to just text, would make it
easier. But I'd go with a full engine based textgrid implementation :-P


> rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands
> being
> > queued to the thread! I wonder why it's not unusable slow, given that it
> > will lock the mutex, append to queue, dequeue and so on :-P
>
> :) just fyi... it is a text draw per call to ENSURE a grid. it can't merge
> into
> a string because it does handle proportional fonts (on a "best effort"
> basis).
> this means we have to FORCE the fonts into the grid by drawing 1 char at a
> time.
>

That I've noticed, even said that in my reply to Tasn.


> The idea is to rewrite textgrid to have its own row_draw() or similar
> > exported to the engine, which can optimize the drawing. First we'll
> tackle
> > the rewrite, but optimizations could be applied later such as collapsing
> > sibling background or line rectangles if color match, doing a single
> > operation.
>
> it's already there. sure - it's not a row draw func.. its just the inner
> for
> (xx = 0... loop - and bg's are collapsed together. strikethrough/underline
> could
> be if that seems an issue (as above - not common enough to worry, but if
> you
> find it more common - sure). the problem is mostly the text. it's a
> bi-product
> of having to maintain a grid.
>
> > That's not one day task, so we'll ask you to wait a bit until it get
> fixed.
>
> sure - but i think we need to discuss the solution as i think you missed
> what
> the code is doing. it first walks the cells and builds a row array - with
> each
> row array being an array of commands "draw rect/text" basically (with
> underline/strikethrough being lines - ie 1 pixel high rects). it THEN
> walks that
> array of "commands" and issues the draw commands in phase 2.
>

that i got, except the merge of rectangles that I supposed were doing
naively, one rect per cell as well.


the question is how to improve this. reality is that we cant convert to
> strings
> WITHOUT having a way to force the string/font/text renderer to enforce a
> grid
> spacing of text - this is one option. but then we re-generate textprops
> all the
> time ... or we have to restructure it in textgrid to not store textprops
> per
> cell but genrate runs at rendering time - but then scrolling means
> re-generate
> as scrolling isnt a special op... we just change the grid array.
>

I'd like to find a way to provide the engine with the array of
Evas_Textgrid_Cellrow, plus some way to get the text information to get the
glyph bitmap.




> another option is the ability to have a "multi textprop draw" cmd added to
> engines - this renders using an array of N textprops so you place a single
> font
> draw cmd on the cmdqueue for the thread but it has multiple tp's attached.
>

this is more likely, unfortunately. But I don't like it that much. It would
be nice to calculate the cutout and similar once and reuse. We could use
this for color, regions, etc.


also textprops are not that small... were we really only need some of the
> data
> in this case... maybe we can trim that down?
>

It's still confusing to me the management of the text props, glyphs and
everything. Seems they are mixed because of previous existence of regular
text layout.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: bar...@gm...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202