On 07/08/2016 18:02, Thomas Lübking wrote:
On Sat, Aug 06, 2016 at 05:18:43PM +0200, Michael Titke wrote:
16 ms ? Usually a hollywood frame needs to be done within 40 ms
But your screen refreshes at snappy 60Hz and not some choppy 24fps :-)
To be more serious, we clamped resizing to 30fps in kwin (for clients
which didn't support the XSYNC protocol) to lower the load on the
client. Reason was that no human being can reasonably control sizes at
that speed anyway and it's still "smooth enough".
Maybe those old WindowMaker routines from the nineties with the one
pixel bitblt inverse frame ... ;-)
Still supported by some WMs. Pace is naturally unbeatable.
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.
After another review that was only XTerm to perform well: some Gnome
Terminal repaints with white during the overloaded window resizes and
konsole prefers to show you the composited frame shadows and the
background of the last resizes for a glimpse.
That's for the baseincrement size hint. Every client can make use of
that but it's oc. very reasonable for clients which display rows and
comlums of chars.
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.
BackingStore, SaveUnder and/or compositors eleminate that problem.
My preliminary solution was the background pixmap of what was drawn
where the backing store needs to be readjusted to the actual window
size. That would have been another great opportunity to run into the
shared memory segment limit and see the desktop come to a halt. Thanks
to cgroup terminating the session is enough to get a working desktop
back but the list of shared segments of my mischiefed stress test
remained in the system data structures and that rebooting attitude ...
That's then the render extension, inter client communication protocol
and xsync as the next extensions to implement. Thank you for the
property and xsync hints!
_______________________________________________
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
