On Fri, 21 Dec 2012 11:55:25 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Friday, December 21, 2012, Ulisses Furquim wrote: > > > Hi, > > > > On Fri, Dec 21, 2012 at 7:49 AM, Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi <javascript:;>> wrote: > > > > > > On Friday, December 21, 2012, Carsten Haitzler wrote: > > > > > > > On Fri, 21 Dec 2012 06:08:09 -0200 Gustavo Sverzut Barbieri > > > > <barbi...@profusion.mobi <javascript:;> <javascript:;>> said: > > > > > > > > > Does it solve the problem? > > > > > > > > > > It's weird because those images should be referenced and pixels kept > > > > until > > > > > rendered. Do you know if someone else is releasing the pixels > > > > > forcefully > > > > > before that? > > > > > > > > > > Also, couldn't you sync only once the canvas at the beginning of the > > > > > function? Or there are multiple canvases? It's not expensive, but > > > > > could > > > > > simplify the code. > > > > > > > > well i did it that way so we sync only if we need to sync on the first > > > > image.. > > > > the other sync's should then be "nops" :) evas in xephyr seems to be > > > > happier > > > > now with sw comp... and yes - comp could SET the pixel data to a new > > ptr > > > > (freeing the old) at any point... > > > > > > > > > I see. We sync before we image_data_get(o, 1). But indeed we'd need to > > > sync > > > if we just image_data_set() a different pointer, leading to creation of a > > > new Image_Entry as the reason might be the old entry pixels were freed. > > > > Maybe we should have the sync inside _image_data_set() like we do have > > for _image_data_get(o, 1)? And then we might not need all these calls > > to evas_sync() spread in comp? > > > That's what I meant. yes. > > Thanks, > > > > -- > > Ulisses Furquim > > ProFUSION embedded systems > > http://profusion.mobi > > Mobile: +55 19 9250 0942 > > Skype: ulissesffs > > > > > > ------------------------------------------------------------------------------ > > 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 > > enlightenment-devel@lists.sourceforge.net <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
