no problem Fred, tell me If I'm right: - when using a buffered window there should be two cairo surfaces (back and front) - a window resize, trigger the re initialisation of all the two surfaces - actually the fresh new surfaces get drawn immediatly (in my case they are white)
I think that there should be always a surface drawble, this mean that we should reallocate the surfaces one at a time. what do you think? On 20 December 2013 10:12, Fred Kiefer <[email protected]> wrote: > Hi Riccardo, > > sorry, I don't do IRC and was away last night. > > What happens on resize is that we have to regenerate the backend surface > all the time. And most likely we are copying over uninitialized data. Or > not drawing at all. The interesting question is who is drawing the black in > between? > > Fred > > On the road > > Am 19.12.2013 um 20:01 schrieb Riccardo Canalicchio < > [email protected]>: > > Hi Fred and thank you for your hint, > I'm doing some debugging to see what happen on resize but It's not simple > for me to understand the logic behind. > Currently I'm on IRC (freenode#gnustep nickname: nongio) if anyone would > like to talk about this issue I would appreciate a lot! > > > On 17 December 2013 22:34, Fred Kiefer <[email protected]> wrote: > >> You are welcome to look into this. Yesterday I tried to use valgrind >> (callgrind in this case) to detect any anomalies, but couldn't spot any >> big performance change to previous versions. >> >> I also made a quick check and the problem shows up with the cairo and >> the art backend, but not with the xlib one. This points in the direction >> of the shared class XWindowBuffer, but that class no longer gets used by >> the modern cairo implementation in GNUstep. There XGCairoModernSurface >> gets used. >> >> My feeling is that the X server tries to draw the window contents while >> we haven't properly set up the surface to draw it. But this might be >> completely off. >> >> Sorry to be of so little help, >> Fred >> >> On 17.12.2013 10:10, Riccardo Canalicchio wrote: >> > yes, I'm using GNUstep from SVN, someone is already working on this >> > problem? >> > If not, I would like to try to find a solution... Could someone please >> give >> > me some hints to start investigate the problem? >> > >> > On 17 December 2013 07:35, Germán Arias <[email protected]> wrote: >> > >> >> Hi, >> >> >> >> I suppose this is with GNUstep from SVN, right? I'm having the same >> >> problem. The window show a black rectangle, that don't fit the window, >> >> while I resize the window. This is not obvious in WindowMaker since, by >> >> default, WM use a "phantom" resize. But if I change this at defaults, I >> >> notice >> >> this problem. However, as far as I remember, the ugly flickering as >> been >> >> there always. >> >> >> >> Germán >> >> >> >> On 2013-12-16 12:38:28 -0600 Riccardo Canalicchio < >> >> [email protected]> wrote: >> >> >> >>> hi all, >> >>> I'm experiencing a very annoying bug: during the resize of a window, >> the >> >>> graphic rectangle occupied by the window starts to flicker until the >> >> resize >> >>> is done. >> >>> When I say flicker I mean that the window content is displayed before >> It >> >> is >> >>> completely drawn. >> >>> I'm using the cairo backend. Is this the default behaviour or I missed >> >> some >> >>> configuration steps? >> >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
