How GDI/GDI+ works without OpenGL or DirectX

Sorry if this is off-topic here. If so; please feel free to move it to the appropriate site.

How does GDI/GDI+ render to the graphics card (display content on the screen) without the use of a lower-level API for communicating with the GPU such as DirectX or OpenGL? How does it draw to the screen without the use of either API? Yes; I know that the image is composited and rendered on the CPU, but then it SOMEHOW has to be sent to the GPU before being disp开发者_如何学Golayed on the monitor. How does this work?

GDI primitives are implemented by the video card driver. The video driver is provided by the GPU manufacturer, and communicates with the GPU using the proprietary register-level interface, no public API needed at this level.

Contrary to what you claim to know, the image is generally not fully rendered and composited on the CPU. Rather, the video driver is free to use any combination of CPU and GPU processing, and usually a large number of GDI commands (especially bit block transfers, aka blitting) are delegated to the GPU.

Since the proprietary interface has to be powerful enough to support the OpenGL client driver and DirectX driver, it's no surprise that the GDI driver can pass commands to the GPU for execution.

Early during boot (and Windows install) when no manufacturer-specific driver is available, the video API does perform all rendering in software and writes to the framebuffer, which is just the memory area which feeds the GPU RAMDAC and mapped into the CPU address space. The framebuffer is stored in one of several well-known formats (defined by VESA).