Part of the logic of this note is to find a place for the sorts of code that comprise modern graphics software. The previous note tries to describe such code in a historical framework.

I assume an object which represents a rectangular pixel array. There may be several facets to a window. We will postpone saying which facets there are and what methods they obey. There is a sub-window relation between windows. Some method enumerates the sub-windows. No method retrieves the window to which this is a sub-window. A window is a sub-window of just one window. Some method on window W returns a reference to a new sub-window of W—arguments are corner coordinates of new window relative to W. The storage of a sub-window of W is a portion of the storage of W. Drawing on a sub-window draws on the window.

Where do windows come from?

Each screen is reified as a window and made available at boot time. A window maker takes a space bank and makes a window with pages from that bank. The sub-window relation forms a tree without cycles. Synchronization is another relation between windows.
I interrupt this presentation to consider the needs of the program that provides window content. But before that there are the needs of the programs that provide low level content such as circle drawers and font mongers. I think that the latter need write access to pixel RAM. These days the size of a pixel is at least a byte which can be addressed with a single store instruction. Drawing primitives need no longer worry about a byte spanning the edge of a window.
Naïve designs presume that high level domain specific software calls levels of evermore pixel oriented software until pixels are computed and situated. The early Macs transcended this plan:

Accumulating Rasters

I think that some schemes need an object with a raster where pixels accumulate. The raster need not show on the screen (design decision). The circumstances for using the old pixel value may be limited to alpha blending or to z-buffer logic. I have not heard of mixing alpha blending and z-buffer logic. then again: With such limitations it is possible to do blind drawing.
Here are some object interfaces that seem required. With such a list it may be possible to invent specific objects that implement or use such interfaces.
A virtual screen (VS)
The mutable state of a VS is its rectangular array of pixels. The size of the array and the shape of its pixels are immutable and determined at creation. The real display may export this interface. These immutable attributes are readable. Optionally the pixels are readable. There is a way to set individual pixels and also to efficiently set rectangular subsets of pixels.

Creation time parameters:

Not all combinations are possible— e.g. one bit pixels don’t have alpha.

The main raison d’être for this interface is low level at which to produce images suitable for code designed to produce pixels but which may be oblivious to questions of real screen space and pixel shape. As specified it is scarcely more than virtual RAM but implementations are presumably suited to make it efficient for actually seeing the pixels. Like all contracts it is for the mutual convenience of the interface provider and user.

The VS may deliver a writable segment (Keykos terminology) holding the pixels. Stores into that segment change the pixels and loads deliver current pixels. The segment is normally kept by a program that needs to run shortly after the pixels change.

See the EROS windows design.