So I wondered how matplotlib (or equivalents) makes graphics appear on your screen.
I found that matplotlib does not do the drawing itself; instead it is built on TKinter, which is built on TK, which is...and the rabbit hole/stack continues.
Is the software package/library/code at the bottom of this stack achieving this by just interfacing with the operating system via assembly code to manipulate pixels on the screen?
I would say at this level of previous knowledge it suffices to say that ultimately, pixels are just memory locations that can be accessed using ordinary read and write operations in any language that allows memory access. There are different possible ways pixel data is organized in memory, but for simplicity you may assume that each pixel could be represented as a three-byte element of red, green and blue intensities in an array of width*height size.
The graphics libraries (and often the associated hardware) knows how to translate x/y coordinates into array indices, how pixel values are combined when pixels shouldn't be fully overwritten for transparency or anti-aliasing etc. But at the end of the day, it's just array elements being read and written.
In many cases, there are additional copying steps involved. For example, a graph drawing library might write pixels into ordinary main memory, and the window system and graphics driver copy these to screen memory.
Whether the high-level code is matplotlib, a text processor, or some game, doesn't really matter.
Drawing is translated to fairly primitive commands at the lowest level. Such as
These commands can be implemented in software using various algorithms 1 2 3. Software rendering may be done by the OS, or the application itself. It may also be hardware accelerated where these commands are sent to dedicated 2D graphics hardware. Commands can also be translated to use the 3D graphics API, so drawing a line may be achieved by drawing a pair of thin triangles for example. The OS may use different methods depending on the API used, the hardware available etc.
There is 50-ish years of research and development on how to efficiently draw graphics, some that has been obsoleted by improvements in hardware and technology. So it is not a topic that can be easily summarized.
I'm not familiar with TK, but as far as I can tell it seems like an abstraction layer on top of the OS, so would translate drawing commands to whatever OS it runs on. But I would not be chocked if things like plots are drawn by the application itself using some software rendering library. Drawing plots are probably not that performance sensitive, and it may be easier to ensure plots look the same on all OSes if you do the drawing yourself.
Long ago applications would do their drawing to a shared frame buffer on the graphics card before sending it to the screen. But for modern operating systems there will be separate buffers for each application/window, and there will very likely be additional buffers as needed. All the frame buffers will be combined by the OS during the "compositing" stage to produce a final image to send to the screen.
