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

[Carsten Haitzler (The Rasterman)]

On Sun, 07 Aug 2016 20:26:37 +0200 Michael Titke <michael.tiedtke at o2online.de>
said:

> 
> 
> 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 

xterm does about the least amount of work. it relies on x background painting
(where x will fill in the default bg for you) so you will have your bg pretty
much correct all the way to window bounds on a resize. it's just the text then
that gets a repaint. this would be the test of the driver pixmap realloc path -
is the driver slow at creating new pixmaps for the compositor? there is
essentially almost nothing to render. the others use different polices and ways
of filling in window content.

> 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 

you ran into a limit? sure. it exists... but i have NEVER hit it in 20+ years.
and i've used x11-shm extn for as long or longer. i even have shm caches that
leave a bunch of segments around for a bit to recycle them as long as frames
are being pumped out regularly (but i don't actually force a full window-sized
shm seg unless the update region *IS* the entire window, thus the smaller
segments to cover update regions and a pool to pull them out of). actually
thanks to a small bug as a result of moving the shm puts off into a thread,
the shm segs were not getting flushed/cleared but would hang about for a long
time as only new allocations would clear out old unused segments beyond the
cache limit (per process limit was 20m). so even then i never hit a limit.

> 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 ...

oh that's an easy fix.

for I in `ipcs -m | grep 0x | grep $USER | awk '{print $2;}' | awk -F r '{print
$1;}'`; do echo -n "Del SHM: $I ";ipcrm shm $I; done

:) just do that every now and again if you have problem children :)

> 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 at 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

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com