On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim <[email protected]> said:
> 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? i have realized another nice little flaw... when u render - by default you expect the results to be done by the time the idle enterer is finished (you enter idle) and if you were to do things like: 1. get window shape rect list if window is shaped - you'd get the shapes OF your rendering... not the previous one. 2. if u get pixel content.. u get the content of what u just rendered, not some previous frame. that means... in real life, we can't turn async on by default... it has to be explicitly requested :/ (at the ecore-evas and even elementary level). otherwise we break api/abi basically (well behaviour). i have also been thinking on this while asleep.. or pretending to be... we have another bug in comp that is implicit due to it not forcibly ordering the comp canvas draw to be AFTER all idle enterers (it should use an idler and manual rendering that it then deletes after first idler spin - but this won't fix out current issue anyway - also we have a shape rect issue too anyway since shape rects are set by ecore-evas's idle enterer but the e_border idle enterer i think executes before , merging shape rects from the frame canvas... anyway my brain is running around in circles with all the implicit dependencies of who renders first and produces what results and then who depends on them for another stage etc.). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
