On Friday, December 21, 2012, Ulisses Furquim wrote: > Hi, > > On Fri, Dec 21, 2012 at 1:09 PM, Ulisses Furquim > <ulis...@profusion.mobi<javascript:;>> > wrote: > > Hi, > > > > On Fri, Dec 21, 2012 at 12:21 PM, Carsten Haitzler > > <ras...@rasterman.com<javascript:;>> > wrote: > >> On Fri, 21 Dec 2012 11:55:25 -0200 Gustavo Sverzut Barbieri > >> <barbi...@profusion.mobi <javascript:;>> 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:;> <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:;> > <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. > > Again, sorry. Can this happen? Aren't we just dropping the reference > for the old entry when doing _image_data_set() with a different > pointer? And it would be actually freed when the rendering stops and > we drop the last reference?
Problem is that the RGBA_Image is referenced, but the image.data was an user pointer and he will free() in order to not leak memory. This is an alternative approach. The other is when you use Evas-allocated with image_data_get(o, 1). That one is correct, the alternative is not. I believe that RGBA_Image->image.no_free or something like that can be used to figure out the case. In that situation you should NULL the image data pointer or evas_sync() before. > > -- Ulisses > > >>> > 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. > > > > Ok, sorry, didn't understand that's what you meant. :-] And so for > > _native_set() as well (and maybe others?). > > -- > 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
