Hey Gustavo, Sorry for the delay. I'll be brief as I don't have much time or energy. :) If you have any further questions, please feel free to ask. If I remember correctly, there are two structures: 1. Evas_Text_Props_Info 2. Evas_Text_Props
The first one is immutable and is refcounted. The second one is mutable and everything goes with it. I guess the lack of a const before Evas_Text_Props_Info *info is confusing, and I think it's an oversight. The *_Info one includes all the info about the glyphs of a run, while the other one represents a part of that run and points to the relevant info. With that being said, this code has changed since I touched it (some adjustments were made by cedric iirc) so my info may be out of date. I hope this helps. -- Tom. On Tue, Dec 4, 2012 at 10:12 PM, Gustavo Sverzut Barbieri < [email protected]> wrote: > Hi all, > > We're working on the Evas threaded and asynchronous render, one > showstopper at the moment is to figure out the expected > Evas_Text_Props lifetime and changes. > > First: Evas threaded and asynchronous render > > Before the threaded render approaches were all based on sending to > thread and waiting the threads to finish their work, thus blocking the > main thread from doing any further work. This was synchronous. > > Now we want to make it asynchronous, a new evas_render_updates_async() > will be created, it will dispatch commands to a thread and return > ASAP. The thread will run the commands and at the end of frame it will > notify using async pipe (same used by PRELOAD). > > Then from the evas_render_updates_async() call to the notification in > the main thread about its finish, we must have a way to either > preserve references immutable, or we must copy them. > > We're sending to the thread just the immediate commands that should be > executed. Then we pre-apply the cutouts and send just the small > pieces: no need to preserve/pass dc->clip or cutouts. > > For rectangle it's super-easy, color is an integer, and we pass it to > the thread. > > For images it's being simplified as now, considering static/immutable > images, and preserving references. (get pixels and images that are > being painted by user will be handled later). > > 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 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?) > > Also, reference is not enough as glyphs array may change. > > 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. > > 2 - copy text_props->glyphs (expensive) > > 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? > > 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? > > Regards, > > -- > 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 > -- Tom. ------------------------------------------------------------------------------ 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
