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. > 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. > 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. > 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. > 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. -- Cedric BAIL ------------------------------------------------------------------------------ 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
