Hi raster, On Monday, January 7, 2013, Carsten Haitzler wrote:
> On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim > <[email protected]<javascript:;>> > said: > > > Hi Raster, > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler > > <[email protected]<javascript:;> > > > > wrote: > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > <[email protected] <javascript:;>> said: > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > >> <[email protected] <javascript:;>>wrote: > > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > >> > <[email protected] <javascript:;>> said: > > >> > > > >> > ooh also.. with software comp.. rememebr that the async renderer is > still > > >> > busy > > >> > rendering in the bg.. THEN sw comp in the mainloop is grabbing > pixels to > > >> > ximages WHILE sw evas is rendering async.. THEN it uses those > ximages - > > >> > their > > >> > pixel data is SET to be theimage pixel data, and then an sync sw > render > > >> > uses > > >> > that pixel data we grabbed async to the rendering of it (that used > to be > > >> > sync) :) if its sw comp - but i've seen sync issues with gl comp and > > >> > content > > >> > containing incorrect pixels. :) > > >> > > >> > > >> I couldn't understand what you mean. Seems you're getting some ideas > on > > >> where is the problem, then: > > >> > > >> 1 - explain that in a more understandable way :-P > > >> 2 - look into comp code to see where the problems could be. You > wrote it, > > >> then you know that quite well. > > >> > > >> We can help you with #2 if you do #1 and let us know where to to pin > point. > > > > > > comp can sync its canvas. it can ensure it is no longer rendering > before it > > > changed the image data ptrs... > > > > > > BUT... it cant sync the canvases in the borders, or the menus, or the > > > background or the popups. these are separate windows and canvases. > > > literally e is doing x(shm)getimage() the pixels from x11 when updates > > > happen. since async rendering may be rendering a NEW frame WHILE it is > > > doing a getimage for the old one (the border canvas is rendering async > to > > > the comp canvas in its own thread), > > > > What do you mean by its own thread here? You did see we have just one > > render thread for all canvases, right? Or am I missing what you really > > said here? > > frame is renderd in sw. it will be in the sw render thread. main comp > canvas > uses gl. it's not in a thread (atm).. and thus it is in parallel to the sw > thread. i've been sleeping on this and sucky as it is.. there's more > problems > to be had with regards to shapes too :/ shape masks that is. I see, you are right. Now the best we can do is a ecore_evas_sync like Gustavo said if we can not do async rendering and one of our sub ecore evas can. If we do async rendering then it shouldn't matter. This way we don't even need to spread calls to evas_sync and when (and if) we make gl engines async it should just work. Agreed? Does it make sense? -- Ulisses, from iPhone > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] <javascript:;> > > -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
