The receive buffer could be a fixed size, and that really plays no part in the receive window, except to place an absolute maximum on the receive window size. The real definition of a receive window is to be found in RFC 793, Transmission Control Protocol, which is the definition of TCP. The receive window is explained in several places in the RFC. For example:
TCP provides a means for the receiver to govern the amount of data
sent by the sender. This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers beyond the
last segment successfully received. The window indicates an allowed
number of octets that the sender may transmit before receiving further
Assume that the receiver has a fixed buffer size of 10,000 bytes and starts with a receive window of that size. If it has received 4,000 bytes, but the application process has not yet consumed those bytes from the receive buffer, TCP will acknowledge the received bytes, but specify the receive window is now 6,000 bytes because that is all that is left in the buffer. The receiver is telling the sender that it should stop sending more data after it sends 6,000 more bytes, unless the receiver gives it a different receive window size. Remember, TCP is a process that is not the application process, and TCP will maintain the connection and the receive window based on its available resources, which are filled until the application process gets around to consuming the data and freeing TCP resources.
It does not show shrinking of window.
The diagram seems to show the send window shrinking and expanding (800 to 600 to 400, and back to 600 on the client). It also shows the receive window (on the server) shrinking as data are received, until the application process consumes some data from TCP, at which point the receive window grows by the amount consumed.
TCP doesn't have clients or servers, it creates connections between two peers, so I'm not sure why the book implies that; it only serves to confuse things. In this case, the client is the sender, and the server is the receiver, and that is backwards from what many people use. Either TCP peer can both send and receive (each is a sender and a receiver). The RFC for TCP doesn't mention clients or servers.