PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)

[Michael Titke]

On 06/08/2016 15:57, Thomas Lübking wrote:
> 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 ;-)
16 ms ? Usually a hollywood frame needs to be done within 40 ms: (even 
if that fixed frame rate approach perhaps doesn't work too well
for interactive use it still might be a good meter to compare to)
> 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.
The example at hand should only show a static image of the hue rainbow. 
For other cases
I was thinking about using the time delta of events and some event 
peeking to skip redraws (extending
the concept of the count field of the events of incomplete redraws).
But that wouldn't help in the case of a resize of a window with a 
background pixmap.

>
> @Michael, try resizing xterm. If that's slow, there's a problem in the
> mechanism. If not, it's just the client.
Other clients perform just the same on the screen when viewed as 
critical as I viewed my current examples.
Maybe those old WindowMaker routines from the nineties with the one 
pixel bitblt inverse frame ... ;-)

Actually the terminal emulators seem to perform better visually: they 
only resize when the resize would add or remove a
row or column from the matrix. In my little experience up until now low 
frequency events result in a much smoother perceived
result: scrolling events result in a perceived smooth movement of a 
simple logo which is redrawn every time. (Single step scrolling
of course reveals the scrolling steps graphically.) Only high frequency 
events will exhibit some sort flickering effect especially
because the window in the frame buffer / on screen is erased by the 
drawing routine of the client when the server already
did that for the expose event.