On Fri, 4 Jan 2013 11:16:14 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Fri, Jan 4, 2013 at 10:54 AM, Carsten Haitzler <ras...@rasterman.com>wrote: > > > On Fri, 4 Jan 2013 10:42:13 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > > On Fri, Jan 4, 2013 at 6:06 AM, Daniel Juyung Seo <seojuyu...@gmail.com > > >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: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
