From: Daniel J. S. <seo...@gm...> - 2013-01-04 08:06:40
|
Hello this is Daniel Juyung Seo. I found a rendering issue today. Window title is not rendered correctly when I resize the windows. Please refer the screenshot: http://www.enlightenment.org/~seoz/render.jpg I have two screens and this happens only with one screen. And I suspect evas async render. Thanks. Daniel Juyung Seo (SeoZ) |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-04 08:24:00
|
On Fri, 4 Jan 2013 17:06:34 +0900 Daniel Juyung Seo <seo...@gm...> said: > Hello this is Daniel Juyung Seo. > I found a rendering issue today. > Window title is not rendered correctly when I resize the windows. > Please refer the screenshot: > http://www.enlightenment.org/~seoz/render.jpg > > I have two screens and this happens only with one screen. > And I suspect evas async render. this has been happening since async render code went in. its a new and shiny feature in this new code. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2013-01-04 12:42:19
|
On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm...>wrote: > Hello this is Daniel Juyung Seo. > I found a rendering issue today. > Window title is not rendered correctly when I resize the windows. > Please refer the screenshot: > http://www.enlightenment.org/~seoz/render.jpg > > I have two screens and this happens only with one screen. > And I suspect evas async render. > It's weird, do you or raster have any facts to backup it's the async render? It could be the async render, but we need more info as it's unlikely: - There is no async render for GL. Then if you're using GL compositor you should have no changes as it's not going to threads. - The images are unlikely to go/deleted, as the border/decoration is reused widely. Moreover we should ref RGBA_Image and this shouldn't happen. - We copy the Draw_Context fields that matter, giving the copy to the thread. If there are modifications to the original Evas_Object it shouldn't affect the image. That said, please share more information about your system. Is it using MMX/SSE? Could you try those Evas environment variables to disable MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some end_cpu()). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Cedric B. <moa...@gm...> - 2013-01-04 13:58:26
|
Le 4 janv. 2013 21:42, "Gustavo Sverzut Barbieri" <bar...@pr...> a écrit : > > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm... >wrote: > > > Hello this is Daniel Juyung Seo. > > I found a rendering issue today. > > Window title is not rendered correctly when I resize the windows. > > Please refer the screenshot: > > http://www.enlightenment.org/~seoz/render.jpg > > > > I have two screens and this happens only with one screen. > > And I suspect evas async render. > > > > It's weird, do you or raster have any facts to backup it's the async render? I also experience it on my two screen setup. It seems to only happen on one of the two screen (left one, same as seoz). I don't remember if I was soft or gl, but soft was likely. It happened just after I upgraded my computer after sync was added. Maybe we should make async an option for the moment ? > It could be the async render, but we need more info as it's unlikely: > - There is no async render for GL. Then if you're using GL compositor you > should have no changes as it's not going to threads. > - The images are unlikely to go/deleted, as the border/decoration is > reused widely. Moreover we should ref RGBA_Image and this shouldn't happen. > - We copy the Draw_Context fields that matter, giving the copy to the > thread. If there are modifications to the original Evas_Object it shouldn't > affect the image. > > That said, please share more information about your system. Is it using > MMX/SSE? Could you try those Evas environment variables to disable > MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some end_cpu()). > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ 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_122812 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-04 12:54:58
|
On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm...>wrote: > > > Hello this is Daniel Juyung Seo. > > I found a rendering issue today. > > Window title is not rendered correctly when I resize the windows. > > Please refer the screenshot: > > http://www.enlightenment.org/~seoz/render.jpg > > > > I have two screens and this happens only with one screen. > > And I suspect evas async render. > > > > It's weird, do you or raster have any facts to backup it's the async render? yes. as this only started happening after the async commit. i get it onb all my machines to some extent or the other and to some windows at random. MOSt of the time i find teh bottom resize bar on windows in default theme will be mis-rendered with the wrong sized content and the rest inheriting "fb garbage". > It could be the async render, but we need more info as it's unlikely: > - There is no async render for GL. Then if you're using GL compositor you > should have no changes as it's not going to threads. indeed - but its the window frame content itself... which is rendered to the frame window with software. :) also be aware that this is rendered first THEN gl compositor canvas picks up the damage events and re-composites the pixmaps within the same process. > - The images are unlikely to go/deleted, as the border/decoration is > reused widely. Moreover we should ref RGBA_Image and this shouldn't happen. > - We copy the Draw_Context fields that matter, giving the copy to the > thread. If there are modifications to the original Evas_Object it shouldn't > affect the image. > > That said, please share more information about your system. Is it using > MMX/SSE? Could you try those Evas environment variables to disable > MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some end_cpu()). i also have seen an async wait for event sit and wait forever and hang e17 - missing an event somewhere. this isnt a bug in the compositor canvas - its a bug in the software canvas that renders to the frame canvas (i havent turned off comp to see if it continues without comp atm when it turns up). :) > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ 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_122812 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-04 12:56:57
|
On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri <bar...@pr...> 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. :) > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm...>wrote: > > > Hello this is Daniel Juyung Seo. > > I found a rendering issue today. > > Window title is not rendered correctly when I resize the windows. > > Please refer the screenshot: > > http://www.enlightenment.org/~seoz/render.jpg > > > > I have two screens and this happens only with one screen. > > And I suspect evas async render. > > > > It's weird, do you or raster have any facts to backup it's the async render? > > It could be the async render, but we need more info as it's unlikely: > - There is no async render for GL. Then if you're using GL compositor you > should have no changes as it's not going to threads. > - The images are unlikely to go/deleted, as the border/decoration is > reused widely. Moreover we should ref RGBA_Image and this shouldn't happen. > - We copy the Draw_Context fields that matter, giving the copy to the > thread. If there are modifications to the original Evas_Object it shouldn't > affect the image. > > That said, please share more information about your system. Is it using > MMX/SSE? Could you try those Evas environment variables to disable > MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some end_cpu()). > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ 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_122812 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2013-01-04 13:16:20
|
On Fri, Jan 4, 2013 at 10:54 AM, Carsten Haitzler <ra...@ra...>wrote: > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> said: > > > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm... > >wrote: > > > > > Hello this is Daniel Juyung Seo. > > > I found a rendering issue today. > > > Window title is not rendered correctly when I resize the windows. > > > Please refer the screenshot: > > > http://www.enlightenment.org/~seoz/render.jpg > > > > > > I have two screens and this happens only with one screen. > > > And I suspect evas async render. > > > > > > > It's weird, do you or raster have any facts to backup it's the async > render? > > yes. as this only started happening after the async commit. i get it onb > all my > machines to some extent or the other and to some windows at random. MOSt > of the > time i find teh bottom resize bar on windows in default theme will be > mis-rendered with the wrong sized content and the rest inheriting "fb > garbage". > > > It could be the async render, but we need more info as it's unlikely: > > - There is no async render for GL. Then if you're using GL compositor > you > > should have no changes as it's not going to threads. > > indeed - but its the window frame content itself... which is rendered to > the > frame window with software. :) also be aware that this is rendered first > THEN > gl compositor canvas picks up the damage events and re-composites the > pixmaps > within the same process. > >From Seoz screenshots it's not the window content. It's the border/decorations. The title bar is wrong. Are you sure this is related to the window contents? Right now we queue the commands to the thread and we ref(RGBA_Image) before. One of them is the destination (canvas) and the other is the source (image/pixels). Inside image_data_get(img, for_write=EINA_TRUE), we force sync. Inside image_data_set(img, NEW_PTR), we force sync. Inside image_native_set(img) we force sync. Do you know of some other places where the image can vanish behind the scenes? Do you think that for the compositor it would be better to have ecore_evas_synchronous_set() that forces synchronous mode? I'd like to avoid that, because E17 is a single process and having it to block while it render is a major drawback :-( > - The images are unlikely to go/deleted, as the border/decoration is > > reused widely. Moreover we should ref RGBA_Image and this shouldn't > happen. > > - We copy the Draw_Context fields that matter, giving the copy to the > > thread. If there are modifications to the original Evas_Object it > shouldn't > > affect the image. > > > > That said, please share more information about your system. Is it using > > MMX/SSE? Could you try those Evas environment variables to disable > > MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some > end_cpu()). > > i also have seen an async wait for event sit and wait forever and hang e17 > - > missing an event somewhere. this isnt a bug in the compositor canvas - its > a > bug in the software canvas that renders to the frame canvas (i havent > turned off comp to see if it continues without comp atm when it turns up). > :) This is also strange, we always queue the END command that wakes up the main thread. This is done as the last step before we return, so it's guaranteed. We must check if the async events are not being lost as they are processed by evas/main thread. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-04 14:48:56
|
On Fri, 4 Jan 2013 11:16:14 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > On Fri, Jan 4, 2013 at 10:54 AM, Carsten Haitzler <ra...@ra...>wrote: > > > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > <bar...@pr...> said: > > > > > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seo...@gm... > > >wrote: > > > > > > > Hello this is Daniel Juyung Seo. > > > > I found a rendering issue today. > > > > Window title is not rendered correctly when I resize the windows. > > > > Please refer the screenshot: > > > > http://www.enlightenment.org/~seoz/render.jpg > > > > > > > > I have two screens and this happens only with one screen. > > > > And I suspect evas async render. > > > > > > > > > > It's weird, do you or raster have any facts to backup it's the async > > render? > > > > yes. as this only started happening after the async commit. i get it onb > > all my > > machines to some extent or the other and to some windows at random. MOSt > > of the > > time i find teh bottom resize bar on windows in default theme will be > > mis-rendered with the wrong sized content and the rest inheriting "fb > > garbage". > > > > > It could be the async render, but we need more info as it's unlikely: > > > - There is no async render for GL. Then if you're using GL compositor > > you > > > should have no changes as it's not going to threads. > > > > indeed - but its the window frame content itself... which is rendered to > > the > > frame window with software. :) also be aware that this is rendered first > > THEN > > gl compositor canvas picks up the damage events and re-composites the > > pixmaps > > within the same process. > > > > >From Seoz screenshots it's not the window content. It's the > border/decorations. The title bar is wrong. > Are you sure this is related to the window contents? the titlebar is part of a canvas that lives in the window border window that is parent to the client window. yes - i am sure. its a software canvas in there. i wrote the code. :) > Right now we queue the commands to the thread and we ref(RGBA_Image) > before. One of them is the destination (canvas) and the other is the source > (image/pixels). > > Inside image_data_get(img, for_write=EINA_TRUE), we force sync. > Inside image_data_set(img, NEW_PTR), we force sync. > Inside image_native_set(img) we force sync. > > Do you know of some other places where the image can vanish behind the > scenes? > > Do you think that for the compositor it would be better to have > ecore_evas_synchronous_set() that forces synchronous mode? I'd like to > avoid that, because E17 is a single process and having it to block while it > render is a major drawback :-( its not the compositor canvas - its the canvas of every single window in e17 - shelf, menus,l borders, popups etc. they are all canvases (ecore-evas)... it jujst so happesn that the border canvases are windows that resize a LOT. > > - The images are unlikely to go/deleted, as the border/decoration is > > > reused widely. Moreover we should ref RGBA_Image and this shouldn't > > happen. > > > - We copy the Draw_Context fields that matter, giving the copy to the > > > thread. If there are modifications to the original Evas_Object it > > shouldn't > > > affect the image. > > > > > > That said, please share more information about your system. Is it using > > > MMX/SSE? Could you try those Evas environment variables to disable > > > MMX/SSE/SSE3 and force pure-C composite (maybe it's missing some > > end_cpu()). > > > > i also have seen an async wait for event sit and wait forever and hang e17 > > - > > missing an event somewhere. this isnt a bug in the compositor canvas - its > > a > > bug in the software canvas that renders to the frame canvas (i havent > > turned off comp to see if it continues without comp atm when it turns up). > > :) > > > This is also strange, we always queue the END command that wakes up the > main thread. This is done as the last step before we return, so it's > guaranteed. > We must check if the async events are not being lost as they are processed > by evas/main thread. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2013-01-04 13:21:34
|
On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler <ra...@ra...>wrote: > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> 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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-04 14:49:00
|
On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler <ra...@ra...>wrote: > > > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > <bar...@pr...> 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), this will be a source of issues. before because evas_render was synchronous, this serialized rendering ensuring it was done in a popup/border etc. BEFORE comp grabbed the pixels and rendered the comp canvas. NOW.. this other rendering may still be underway in parallel. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Ulisses F. <ul...@pr...> - 2013-01-07 20:36:42
|
Hi Raster, On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler <ra...@ra...> wrote: > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> said: > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler <ra...@ra...>wrote: >> >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri >> > <bar...@pr...> 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? -- Ulisses > this will be a source of issues. before because evas_render was > synchronous, this serialized rendering ensuring it was done in a popup/border > etc. BEFORE comp grabbed the pixels and rendered the comp canvas. NOW.. this > other rendering may still be underway in parallel. -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs |
From: Gustavo S. B. <bar...@pr...> - 2013-01-07 21:18:48
|
On Mon, Jan 7, 2013 at 6:36 PM, Ulisses Furquim <ul...@pr...>wrote: > Hi Raster, > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler <ra...@ra...> > wrote: > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > <bar...@pr...> said: > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler <ra...@ra... > >wrote: > >> > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > >> > <bar...@pr...> 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? > Expanding Ulisses explanation a bit: 1 - just software_x11 uses threads right now. Buffer doesn't. Then if the border canvases are software, they are synchronous. 2 - we have a single thread share by ALL canvases. Then if every canvas were async (see #1, they are not), the commands from the sub-canvases would be executed BEFORE the commands for the parent. IOW, when comp canvas uses the pixels from borders, the borders would be ready/painted (but see #1). do we know a point where border canvas are updated? Do we do it at once, or multiple times? Could you do a forced evas_sync() BEFORE start to paint sub canvases? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-07 23:44:07
|
On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim <ul...@pr...> said: > Hi Raster, > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler <ra...@ra...> > wrote: > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > <bar...@pr...> said: > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > >> <ra...@ra...>wrote: > >> > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > >> > <bar...@pr...> 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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Ulisses F. <ul...@pr...> - 2013-01-08 01:13:20
|
Hi raster, On Monday, January 7, 2013, Carsten Haitzler wrote: > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim <ul...@pr...<javascript:;>> > said: > > > Hi Raster, > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler <ra...@ra...<javascript:;> > > > > wrote: > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > <bar...@pr... <javascript:;>> said: > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > >> <ra...@ra... <javascript:;>>wrote: > > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > >> > <bar...@pr... <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) ra...@ra... <javascript:;> > > -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs |
From: Gustavo S. B. <bar...@pr...> - 2013-01-08 01:27:39
|
On Monday, January 7, 2013, Ulisses Furquim wrote: > Hi raster, > > On Monday, January 7, 2013, Carsten Haitzler wrote: > > > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim < > ul...@pr... <javascript:;><javascript:;>> > > said: > > > > > Hi Raster, > > > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler < > ra...@ra... <javascript:;><javascript:;> > > > > > > wrote: > > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > > <bar...@pr... <javascript:;> <javascript:;>> said: > > > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > > >> <ra...@ra... <javascript:;> <javascript:;>>wrote: > > > >> > > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > > >> > <bar...@pr... <javascript:;> <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? > Not to me. What is being done async if all uses is buffer & GL?! There is no async in these cases. > -- Ulisses, from iPhone > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... <javascript:;><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 > enl...@li... <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Ulisses F. <ul...@pr...> - 2013-01-08 01:34:54
|
Hi, On Monday, January 7, 2013, Gustavo Sverzut Barbieri wrote: > On Monday, January 7, 2013, Ulisses Furquim wrote: > > > Hi raster, > > > > On Monday, January 7, 2013, Carsten Haitzler wrote: > > > > > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim < > > ul...@pr... <javascript:;> <javascript:;><javascript:;>> > > > said: > > > > > > > Hi Raster, > > > > > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler < > > ra...@ra... <javascript:;> <javascript:;><javascript:;> > > > > > > > > wrote: > > > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > > > <bar...@pr... <javascript:;> <javascript:;> > <javascript:;>> said: > > > > > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > > > >> <ra...@ra... <javascript:;> <javascript:;> > <javascript:;>>wrote: > > > > >> > > > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > > > >> > <bar...@pr... <javascript:;> <javascript:;> > <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? > > > > Not to me. What is being done async if all uses is buffer & GL?! There is > no async in these cases. Right. We should not have. :-/ Now to check if we are setting the can_async_render really only for sw_x11. Raster, are you sure we are mixing async and sync the way you said? -- Ulisses > > > > -- Ulisses, from iPhone > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) ra...@ra...<javascript:;><javascript:;><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 > > enl...@li... <javascript:;> <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... <javascript:;> > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > 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 > enl...@li... <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-08 02:16:11
|
On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim <ul...@pr...> said: > Hi raster, > > On Monday, January 7, 2013, Carsten Haitzler wrote: > > > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim > > <ul...@pr...<javascript:;>> said: > > > > > Hi Raster, > > > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler > > > <ra...@ra...<javascript:;> > > > > > > wrote: > > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > > <bar...@pr... <javascript:;>> said: > > > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > > >> <ra...@ra... <javascript:;>>wrote: > > > >> > > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > > >> > <bar...@pr... <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) ra...@ra... |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-08 02:16:16
|
On Mon, 7 Jan 2013 23:27:32 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > On Monday, January 7, 2013, Ulisses Furquim wrote: > > > Hi raster, > > > > On Monday, January 7, 2013, Carsten Haitzler wrote: > > > > > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim < > > ul...@pr... <javascript:;><javascript:;>> > > > said: > > > > > > > Hi Raster, > > > > > > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler < > > ra...@ra... <javascript:;><javascript:;> > > > > > > > > wrote: > > > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > > > <bar...@pr... <javascript:;> <javascript:;>> said: > > > > > > > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > > > >> <ra...@ra... <javascript:;> <javascript:;>>wrote: > > > > >> > > > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > > > >> > <bar...@pr... <javascript:;> <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? > > > > Not to me. What is being done async if all uses is buffer & GL?! There is > no async in these cases. it doesnt use buffer. it uses software-x11 for menus, popups, shelves, window frames etc. > > -- Ulisses, from iPhone > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > The Rasterman (Carsten Haitzler) ra...@ra... > > > <javascript:;><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 > > enl...@li... <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Ulisses F. <ul...@pr...> - 2013-01-08 02:19:37
|
Hi, On Tue, Jan 8, 2013 at 12:15 AM, Carsten Haitzler <ra...@ra...> wrote: > On Mon, 7 Jan 2013 23:27:32 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> said: > >> On Monday, January 7, 2013, Ulisses Furquim wrote: >> >> > Hi raster, >> > >> > On Monday, January 7, 2013, Carsten Haitzler wrote: >> > >> > > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim < >> > ul...@pr... <javascript:;><javascript:;>> >> > > said: >> > > >> > > > Hi Raster, >> > > > >> > > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler < >> > ra...@ra... <javascript:;><javascript:;> >> > > > >> > > > wrote: >> > > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri >> > > > > <bar...@pr... <javascript:;> <javascript:;>> said: >> > > > > >> > > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler >> > > > >> <ra...@ra... <javascript:;> <javascript:;>>wrote: >> > > > >> >> > > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri >> > > > >> > <bar...@pr... <javascript:;> <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? >> > >> >> Not to me. What is being done async if all uses is buffer & GL?! There is >> no async in these cases. > > it doesnt use buffer. it uses software-x11 for menus, popups, shelves, window > frames etc. Ugh. :-/ -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs |
From: Ulisses F. <ul...@pr...> - 2013-01-08 02:26:01
|
Hi, On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <ra...@ra...> wrote: > On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim <ul...@pr...> said: > >> Hi raster, >> >> On Monday, January 7, 2013, Carsten Haitzler wrote: >> >> > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim >> > <ul...@pr...<javascript:;>> said: >> > >> > > Hi Raster, >> > > >> > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler >> > > <ra...@ra...<javascript:;> >> > > >> > > wrote: >> > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri >> > > > <bar...@pr... <javascript:;>> said: >> > > > >> > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler >> > > >> <ra...@ra... <javascript:;>>wrote: >> > > >> >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri >> > > >> > <bar...@pr... <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. 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) ra...@ra... > -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-08 03:12:33
|
On Tue, 8 Jan 2013 00:25:55 -0200 Ulisses Furquim <ul...@pr...> said: > Hi, > > On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <ra...@ra...> > wrote: > > On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim <ul...@pr...> > > said: > > > >> Hi raster, > >> > >> On Monday, January 7, 2013, Carsten Haitzler wrote: > >> > >> > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim > >> > <ul...@pr...<javascript:;>> said: > >> > > >> > > Hi Raster, > >> > > > >> > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler > >> > > <ra...@ra...<javascript:;> > >> > > > >> > > wrote: > >> > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > >> > > > <bar...@pr... <javascript:;>> said: > >> > > > > >> > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > >> > > >> <ra...@ra... <javascript:;>>wrote: > >> > > >> > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > >> > > >> > <bar...@pr... <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) ra...@ra... > > > > > > -- > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2013-01-08 12:34:20
|
I'll reply later, but I guess we are creating a confusion on what could be the problem and it should be much simpler than what you think. Software -X11 used by popups/shelves shouldn't matter as they go to X before coming to the compositor... Unless ther is a shortcut I don't know. And we just XShmPutImage on the main thread. So should be fine. On Tuesday, January 8, 2013, Carsten Haitzler wrote: > On Tue, 8 Jan 2013 00:25:55 -0200 Ulisses Furquim <ul...@pr...> > said: > > > Hi, > > > > On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <ra...@ra...> > > wrote: > > > On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim < > ul...@pr...> > > > said: > > > > > >> Hi raster, > > >> > > >> On Monday, January 7, 2013, Carsten Haitzler wrote: > > >> > > >> > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim > > >> > <ul...@pr...<javascript:;>> said: > > >> > > > >> > > Hi Raster, > > >> > > > > >> > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler > > >> > > <ra...@ra...<javascript:;> > > >> > > > > >> > > wrote: > > >> > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > >> > > > <bar...@pr... <javascript:;>> said: > > >> > > > > > >> > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > >> > > >> <ra...@ra... <javascript:;>>wrote: > > >> > > >> > > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > >> > > >> > <bar...@pr... <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 > > 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) ra...@ra...<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 > > enl...@li... <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... <javascript:;> > > > > ------------------------------------------------------------------------------ > 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 > enl...@li... <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2013-01-08 20:57:40
|
Hi Raster, Please check my study at http://trac.enlightenment.org/e/wiki/Evas_Async_And_E_Comp Quite long, but it was required to get me to understand what is happening. On Tue, Jan 8, 2013 at 10:34 AM, Gustavo Sverzut Barbieri < bar...@pr...> wrote: > I'll reply later, but I guess we are creating a confusion on what could be > the problem and it should be much simpler than what you think. > > Software -X11 used by popups/shelves shouldn't matter as they go to X > before coming to the compositor... Unless ther is a shortcut I don't know. > And we just XShmPutImage on the main thread. So should be fine. > > > On Tuesday, January 8, 2013, Carsten Haitzler wrote: > >> On Tue, 8 Jan 2013 00:25:55 -0200 Ulisses Furquim <ul...@pr...> >> said: >> >> > Hi, >> > >> > On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <ra...@ra... >> > >> > wrote: >> > > On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim < >> ul...@pr...> >> > > said: >> > > >> > >> Hi raster, >> > >> >> > >> On Monday, January 7, 2013, Carsten Haitzler wrote: >> > >> >> > >> > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim >> > >> > <ul...@pr...<javascript:;>> said: >> > >> > >> > >> > > Hi Raster, >> > >> > > >> > >> > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler >> > >> > > <ra...@ra...<javascript:;> >> > >> > > >> > >> > > wrote: >> > >> > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri >> > >> > > > <bar...@pr... <javascript:;>> said: >> > >> > > > >> > >> > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler >> > >> > > >> <ra...@ra... <javascript:;>>wrote: >> > >> > > >> >> > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri >> > >> > > >> > <bar...@pr... <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 >> > 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) ra...@ra... >> > > >> > >> > >> > >> > -- >> > 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 >> > enl...@li... >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> >> -- >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> The Rasterman (Carsten Haitzler) ra...@ra... >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2013-01-08 22:55:08
|
On Tue, 8 Jan 2013 10:34:14 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > I'll reply later, but I guess we are creating a confusion on what could be > the problem and it should be much simpler than what you think. > > Software -X11 used by popups/shelves shouldn't matter as they go to X > before coming to the compositor... Unless ther is a shortcut I don't know. > And we just XShmPutImage on the main thread. So should be fine. our putimage is not async? > On Tuesday, January 8, 2013, Carsten Haitzler wrote: > > > On Tue, 8 Jan 2013 00:25:55 -0200 Ulisses Furquim <ul...@pr...> > > said: > > > > > Hi, > > > > > > On Tue, Jan 8, 2013 at 12:14 AM, Carsten Haitzler <ra...@ra...> > > > wrote: > > > > On Mon, 7 Jan 2013 23:13:13 -0200 Ulisses Furquim < > > ul...@pr...> > > > > said: > > > > > > > >> Hi raster, > > > >> > > > >> On Monday, January 7, 2013, Carsten Haitzler wrote: > > > >> > > > >> > On Mon, 7 Jan 2013 18:36:32 -0200 Ulisses Furquim > > > >> > <ul...@pr...<javascript:;>> said: > > > >> > > > > >> > > Hi Raster, > > > >> > > > > > >> > > On Fri, Jan 4, 2013 at 12:45 PM, Carsten Haitzler > > > >> > > <ra...@ra...<javascript:;> > > > >> > > > > > >> > > wrote: > > > >> > > > On Fri, 4 Jan 2013 11:21:28 -0200 Gustavo Sverzut Barbieri > > > >> > > > <bar...@pr... <javascript:;>> said: > > > >> > > > > > > >> > > >> On Fri, Jan 4, 2013 at 10:56 AM, Carsten Haitzler > > > >> > > >> <ra...@ra... <javascript:;>>wrote: > > > >> > > >> > > > >> > > >> > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > > >> > > >> > <bar...@pr... <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 > > > 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) ra...@ra...<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 > > > enl...@li... <javascript:;> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... <javascript:;> > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > enl...@li... <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2013-01-09 00:04:08
|
On Tue, Jan 8, 2013 at 8:32 PM, Carsten Haitzler <ra...@ra...>wrote: > On Tue, 8 Jan 2013 10:34:14 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> said: > > > I'll reply later, but I guess we are creating a confusion on what could > be > > the problem and it should be much simpler than what you think. > > > > Software -X11 used by popups/shelves shouldn't matter as they go to X > > before coming to the compositor... Unless ther is a shortcut I don't > know. > > And we just XShmPutImage on the main thread. So should be fine. > > our putimage is not async? > it is async, but runs in the main thread, when it comes back. Please see trac.enlightenment.org/e/wiki/Evas_Async_And_E_Comp note that it is up to the engine to call this from thread or not. for software_x11 we choose to do not. Engine can base its decision on evas render_mode variable that is one of: EVAS_RENDER_MODE_ASYNC_INIT: async render, during queueing. engine may queue something to the thread. EVAS_RENDER_MODE_ASYNC_END: async render, after returns to main loop (we call it from here) EVAS_RENDER_MODE_SYNC: synchronous mode, do as before. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |