ASCII Bytesart 1
How does string data get to a screen
When I first looked into the concept of punching a key on my computer and a character magically appearing on the screen seemed easy enough. The OS just looks up the ASCII code in a table and sends the corresponding letter, number, or punctuation to the GPU to put on the screen. This is a naive description of what really goes on. So where is this table stored? How does the OS deal with row and column look-ups anyway? What about fonts? Do all OSs deal with characters the same?
The ASCII table is a encoding scheme not a decoding device. What you see on the screen is a text rendering after a lot of processing and that's just for one character. How about a bunch of text? For that matter, how is string data or a whole document worth of text stored in a file? Is it ASCII bytes, glyphs, SVGs? This is where the road forks. It depends on the OSs or third party libraries or several conversion choices to render fonts and language peculiarities. This is why the DOCTYPE meta data on an HTML page needs to show the text encryption tag. We in the English speaking world don't pay attention because the default is UTF-8 ASCII. Most other places have to know what to put in this tag.
Like most major categories in computer science, there are a lot of different approaches and revisions that supersede what came before. I will just describe generalities but attempt to go beyond the thought that pushing a ASCII 65dec or the byte 01000001 into a text buffer will get an "A" printed on your screen. It's a start but a lot happens before the pixel layout is generated to do exactly that.
Here's the quick and dirty description of what's going on:
Fetching the data: The CPU reads the byte data from the computer's memory or storage device. The data could be
part of a
file, a data buffer, or input from a user's keyboard.
Character Encoding: The data is assumed to be encoded using a specific character encoding scheme, such as ASCII or UTF-8. ASCII uses 7 bits per character, while UTF-8 can use up to 8, 16, 24, or 32 bits depending on the character being represented.
Framebuffer: The GPU utilizes a special region in the computer's memory known as the framebuffer. The framebuffer is a memory buffer that holds the pixel data representing what is currently displayed on the screen. Each pixel is typically represented by a certain number of bits, depending on the color depth and resolution of the screen.
Graphics Libraries and APIs: To interact with the GPU, the operating system and applications use graphics libraries and APIs (Application Programming Interfaces) such as DirectX or OpenGL. These libraries provide a set of functions that allow software to communicate with the GPU and issue commands for rendering graphics and text.
Rendering Pipeline: When an application or the operating system wants to display something on the screen, it sends rendering commands to the GPU through the graphics API. The rendering commands define how the graphics or text should be displayed, including information about geometry (shapes, positions), textures, colors, intensity, and other visual attributes.
Vertex Processing: The GPU's vertex processing stage handles geometric transformations, such as translating, rotating, and scaling the shapes. It processes the vertices (corner points) of the shapes to create the appropriate transformation matrices.
Rasterization: In this step, the GPU converts the geometric shapes into individual pixels. Rasterization involves determining which pixels within the shape boundaries should be filled in and which should be left empty.
Fragment Processing: The GPU processes each pixel (fragment) produced during rasterization. It applies textures, shading, lighting, intensity, and other visual effects to determine the final color and appearance of each pixel.
Output to Framebuffer: After fragment processing, the GPU writes the final pixel data back to the framebuffer. The framebuffer now holds the updated information about what should be displayed on the screen. So these APIs have become defacto text, graphic, and image mediaries for all computers.
Display Refresh: The GPU cooperates with the display controller, a hardware component responsible for sending the pixel data from the framebuffer to the physical display. The display controller refreshes the screen multiple times per second (typically 60Hz or higher), and during each refresh cycle, it reads the pixel data from the framebuffer and updates the physical display accordingly. This makes sense because each monitor or TV screen hardware has its limitations.
Okay, not quick and dirty... there's more!