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