[PATCH 00/37] Implement backing store's Always mode

Adam Jackson ajax at redhat.com
Wed Oct 8 08:04:24 PDT 2014


The charm, and the danger, in working on enterprise operating systems is you
get held accountable for your work.  Once upon a time I reimplemented
backing store in terms of Composite's automatic redirection.  I still think
that was a good idea, and it does work pretty well, but it turns out there are
customers with apps that rely on promises the old implementation made.

Probably the biggest issue with the new code is we don't really honor the
Always mode any differently from the WhenMapped mode, because Composite doesn't
allocate a window pixmap for windows that are redirected but not realized [1].
In other words, if you create a window, set it to Always, and draw to it
without mapping it, your rendering will be thrown away; if you then try to blit
from that window to a realized window, you will instead get a background tile
and a GraphicsExpose instead of your app's actual content [2].

Making composite allocate the window pixmap even for unrealized windows is
pretty straightforward, but not sufficient to make things actually work.  The
old BS code would intercept rendering to backed windows and direct it to
pixmaps.  The new code just draws to the window as if it were mapped, but
since it's not, the clip list ends up being empty.  This series attempts to
detangle the mess.

1-16 are basically a resend of a previous series [3].  18 introduces a new
window state bit called "paintable".  19 through 32 port the output bits of
mi and dix to inspect paintable instead of viewable.  33 through 37 change
the bs implementation in composite to realize bs in more situations.

I'm not in any way convinced this is correct yet, in fact I'm pretty sure
it's not.  And there's some work that would be nice to follow this with [4].
But it's close enough that I'd like to get some more eyes on it.

[1] - Careful readers will note this means we also don't honor the spirit of
the law for WhenMapped.

[2] - Hilariously, if your app was correctly written to expect the
GraphicsExpose, interpret it as the server losing the backing store bits, and
repaint them to regenerate the content, you will be punished for your good
faith with an infinite loop: the repaint to the unmapped window will have no
effect, you'll redo the blit, you'll get another GraphicsExpose...

[3] - Excluding the "can't happen" bit, which I'm not entirely sure I was
correct about, that series would be:
http://lists.freedesktop.org/archives/xorg-devel/2014-September/043960.html

[4] - In particular, fixing the WhenMapped implementation to not really
mean WhenRealized, and lazily redirecting the window based on whether it's
actually clipped.

- ajax



More information about the xorg-devel mailing list