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.
_______________________________________________
[email protected]: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
