Computer Science Stack Exchange is a question and answer site for students, researchers and practitioners of computer science. It only takes a minute to sign up.
Sign up to join this community
recently i started studying computer science and computer graphics, and one question really haunts me. Mby someone can explain this. How bit patterns become translated into (for example ) text. I know we have encoding like ascii and unicode but this is also just bit patterns. Main mystery is at what point do the bits turn into what we see on the screen? So maybe you have some resources which can explain it? How bits translated into text? Thanks.
Most often, bits are not translated into text. They are translated to RGB colours pixel by pixel on a framebuffer found into RAM. The colours will be arranged pixel by pixel to make it look like a letter appeared on the screen but it is simply some pixels arranged in a pattern to make it look like a letter.
Today, everything is PCI including graphics cards (and even the integrated graphics card in the CPU). PCI works with MMIO. You write to some conventional position in RAM and it will write to the registers of the PCI device. PCI devices have conventional configuration spaces found in RAM. The beginning of the configuration spaces can be found in the MCFG ACPI table (see https://wiki.osdev.org/ACPI).
Among PCI devices, graphics cards are the least standardized and the hardest to drive. The way they work is often not mentioned anywhere and you are left to either use an existing OS for which the graphics card manufacturer has provided a driver or use the integrated graphics card for which documentation is open. If you want to drive a discrete graphics card from a custom OS, it will be very hard if not impossible.
Most computer comes with firmware which understands the things they need to drive. For example, the UEFI implementation of an x86-64 motherboard can drive the integrated graphics card of your Intel/AMD CPU. It will thus set this integrated graphics card into a framebuffer mode that can be set (the width and the height and other things) using the UEFI system call interface. A framebuffer is where the screen is simply represented in RAM as an array of pixels. You write RGB colors in order in RAM to make things look like letters or to show an image (or a window or anything else).
To drive more complex discrete graphics cards, an existing OS will present a modular driver model. The modular driver model often takes the shape of a virtual filesystem where every device is presented to the upper layer of the OS as a file. For example, Linux will present a virtual character device file called /dev/dri/card0 for the integrated graphics card.
To drive the card, user mode will often communicate through sockets with the X server which is a special process which is started as the "master" and as a privileged (sudo) process. The X server will make system calls in the Linux kernel to write to the screen.
When using more complex graphics card (that aren't in a framebuffer mode), the graphics card vendor doesn't have a choice but to provide a user mode library to drive the card. This is often an OpenGL (or any 3D rendering convention) implementation. The implementation of OpenGL will drive the card by first opening the /dev/dri/card0 file and then make mostly ioctl() system calls on the file. The ioctl() call has a request argument which is an unsigned long and a variable amount of arguments after. The ioctl() call thus allows to implement any number of operations on the file.
Underneath, the kernel driver (often called kernel module) will do complex things like writing to the PCI registers of the graphics card to ask the graphics card to do some complex operations like drawing. PCI devices are DMA so they can directly read/write RAM without involving the CPU.
On machines with a CRT, this was implemented in the display hardware. As the line scanning took place, the value of the character at the row/column position was obtained from RAM, and that value was used to look up on the fly a hard-coded character map (in ROM), storing a binary representation of the characters. This is how the hardware knew if the current dot was to be on or off.
Nowadays, characters are painted in a graphical memory buffer, possibly using sophisticated rendering algorithms to give the characters the best appearance. The characters are described by font files (in a vector form), stored on disk, and the system can paint the characters at the desired sizes on demand, with antialiasing.
What happens on a more modern computer: You start with an abstract character. The character may be an ASCII character, a Cyrillic character, a Japanese character etc. The developer of your software has decided to draw that character using some font, and some font size.
Some software on your computer takes the font, and decides which glyph to use. A glyph is basically "what a character is supposed to look like". For example, a capital Latin A and a capital Greek Alpha are supposed to look exactly the same, they are the same glyph.
Now most likely your computer has a description of the font, for example a Truetype font, which has one or more curves for describing what the glyph looks like, depending on the glyph, the font, and the font size, possibly other attributes like weight (light, bold, extra bold, slanted, or italic).
Some software turns those lines into an image consisting of pixels, and draws the image on the right place on the screen. That's complicated in its own right, because the glyph can also have a colour, it can be opaque or more or less transparent, and it can be cut off if it doesn't fit where it should go on the screen.
