On Tue, 8 Jan 2013 00:25:55 -0200 Ulisses Furquim <[email protected]> said:
> Hi, > > On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <[email protected]> > wrote: > > 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. > > Right, if we have those assumptions can we do one of the following? > > 1. wait rendering, or > 2. check if rendering and postpone the operation to post render, or > 3. be "discarded" in order to be tried again later, or > 4. become async as well to ensure ordering. we can.. but we can't break ecore-evas/elm etc. "by default" to require any apps/code to adapt like this. it has to be voluntary opt-in to go async. :/ > Or not? :-) > > -- Ulisses > > > 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] > > > > > > -- > 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 > -- ------------- 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
