PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Sun Aug 7 09:45:29 UTC 2016
On Sat, 6 Aug 2016 15:57:23 +0200 Thomas Lübking <thomas.luebking at 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) raster at rasterman.com
More information about the xorg
mailing list