On Wed, Dec 5, 2012 at 9:22 AM, Cedric BAIL <[email protected]> wrote: > Hello, > > On Wed, Dec 5, 2012 at 7:12 AM, Gustavo Sverzut Barbieri > <[email protected]> wrote: >> But for text, it's hard to understand Evas_Text_Props lifetime. >> >> It seems that these are mutable from evas_object_text.c when you ask a >> layout (text_set). Then if the thread is rendering and user text_set() >> it will crash. > > There is something bad here, the fact is that we do build the > text_prop 2 times. Once for the layout and once for the rendering > (then we keep it around). It would be really more nicer to keep it > around as soon as the layout is done. > >> There are evas_common_text_props_content_ref(), >> evas_common_text_props_content_nofree_unref() and >> evas_common_text_props_content_unref(), but particularly the later >> won't work as it free the text_props->glyph right before checking >> references (bug?) > > Seems like a bad behavior to me in fact, but I guess current code can > survive because it will recreate it in a synchronous way. Maybe Tom > will have a better idea here. > >> Also, reference is not enough as glyphs array may change. > > Where ? It should not ! Once the glyphs is created, it should not > change anymore.
it does, it's an array that represents the glyphs for the current text. Change text, change glyphs ARRAY. I'm talking about the array of Evas_Glyph* text_props->glyphs (btw it could use eina_array/inarray to avoid the growth/realloc logic in there). >> I'm envisioning the following alternatives, but I'd like some more >> experienced comments before doing them (Tasn, Raster, Cedric?): >> >> 1 - steal text_props->glyphs, setting it to NULL (and length = 0) >> when we send it to thread, free from thread after it's done >> processing. > > No, no ! We do keep glyph around because rebuilding them is costly and > does impact our performance. It is also a really common pattern to > keep the same text on screen for a time long enough to read it. So a > lot of frame with the same text_prop. Again, array, not the actual glyph in the array! >> 2 - copy text_props->glyphs (expensive) > > 3 - Use a proper refcounting, ref it before spawning it to the > rendering process and unref it when the async callback come in the > main loop. My fear is that I'm far from knowing all the users of text_props->glyphs and it's hard to grep all possible cases. It seems that the glyphs array is not mutable, people just destroy old and create new, in that case, yes the reference would work. But if someone is smart to just change parts of it... we may go into problems :-/ Tasn, do you know this part? Raster? >> Seems #1 is doable, comments? >> >> Also, during the render there seems to be no need for text_props, then >> we can ignore its references and just use glyphs? > > Yes, we should now be able to do that. I did split the generation of > the glyph from the actual render time. I was expecting that you could > delay it as long as possible and make that happen in a thread. elaborate on that? what do you want to create in the thread? generation of glyph in main, render in worker thread? >> Later on, the thread will be using the glyphs and their associated >> render bitmaps, is there any danger they will be destroyed/changed >> from main thread while the render is being done? Font cache flush? > > It should not, if properly refcounted. At least that was my intend. where does it ref/unref the Evas_Glyph and particularly its pixels/data? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
