diff --git a/doc/Xserver-spec.xml b/doc/Xserver-spec.xml
index 20c6cff85..476be4322 100644
--- a/doc/Xserver-spec.xml
+++ b/doc/Xserver-spec.xml
@@ -3285,9 +3285,8 @@ need to be done when these happen, such as allocating or deallocating
structures that are only needed for visible windows. RealizeWindow
does NOT draw the window border, background or contents;
UnrealizeWindow does NOT erase the window or generate exposure events
-for underlying windows; this is taken care of by DIX. DIX does,
-however, call PaintWindowBackground() and PaintWindowBorder() to
-perform some of these.
+for underlying windows; this is taken care of by DIX.
+
@@ -3391,7 +3390,7 @@ and all of its child windows.
If generateExposures is false, the client is trying to simply erase part
of the window to the background fill style.
ClearToBackground should write the background color or tile to the
-rectangle in question (probably using PaintWindowBackground).
+rectangle in question.
If w or h is zero, it clears all the way to the right or lower edge of the window.
The sample server implementation is in Xserver/mi/miwindow.c.
@@ -4052,7 +4051,7 @@ returned instead). Furthermore, the invalid bits of the source are
not copied to the destination and (when the destination is a window)
are filled with the background tile. The sample routine
miHandleExposures generates the appropriate return value and fills the
-invalid area using pScreen->PaintWindowBackground.
+invalid area.
For instance, imagine a window that is partially obscured by other
windows in front of it. As text is scrolled on your window, the pixels
@@ -4994,8 +4993,6 @@ mi and fb implementations.
ModifyPixmapHeadermiScreen
NextAvailableClientdix
OsInitos
-PaintWindowBackgroundmiWindow
-PaintWindowBordermiWindow
PointerNonInterestBoxhdScreen
PointInRegionmiScreen
PolyArcmiGC op