On Sat, 6 Aug 2016 15:57:23 +0200 Thomas Lübking <thomas.luebk...@gmx.de> said:
> On Sat, Aug 06, 2016 at 09:03:04PM +0900, Carsten Haitzler wrote: > > >no. this is just how it goes. because everything is async, the compositor/wm > >has resized the window, then some small time later the client gets a > >configurenotify event, then client renders some update, then sends to x, > >then x tells compositor of a new damage, compositor gets event goes "ooh > >time to draw", compositor draws, talks to x again to display... > > Though the dealbreaker is usually just the clients re-layouting, maybe > sometimes broken XSYNC implementations. > Less the roundtrip itself (which tends to be << 16ms ;-) xsync? you are assuming clients even do an xsync protocol with wm to sync things. there is still a race condition here as wm resizes window first, and client some time later responds with a redraw. xsync really has a limited scope for improvement here. > The solution to this is usually lazy updates by allowing for internal scaling > or padding (if your client has significant payload here) - or anything > else to make the client resize faster. even then frame from wm and client content aren't going to match. :) also one of the big issues here is pixmap re-allocation if composited. this can actually be rather slow on some drivers with continual resizing and it can drop framerate down to 10fps etc. even in your xterm example below. > @Michael, try resizing xterm. If that's slow, there's a problem in the > mechanism. If not, it's just the client. > > Cheers, > Thomas > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
