Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)
Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.
Slashdot Mirror
Likely the GTK+ developer was me. I certainly didn't say that X has no concept of backing store. I may well have indicated that the current X implementation of backing store quite typically does more harm than good. For instance, under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds in the windows backing store. (Having traced through the X server code to figure out why this was happening some years ago, I can authoritatively say that X does have a concept of backing store.)
Keith's new extension is quite different from traditional X backing store; the obvious difference is the ability to control how the windows are composited to the screen. But there are other differences; the server, for instance, uses only a single backing store buffer for the entire toplevel window, instead of one for each subwindow.