How do C graphic libraries work?

Question

How graphic libraries work?

For example, the standard C execution mode is the application console, as from that only text can create the graphical libraries where you understand pixel instead of letters and characters? how they transform text into images, vectors, etc?

How is this process of entering graphic mode?

How do I create a graphical library?

Answer 1

To make graphics appear on the screen, there are several layering:

1. The creators of graphics cards, motherboards, monitors define a way for these parties to communicate. For example, set the X pin with a Y bit, wait as many nanoseconds, read the bytes in Z address, etc. These conventions can follow standards such as PCI or PCI Express buses, connection with VGA monitor or HDMI, etc. You will only work at this level if you mess with hardware or operating systems.
2. The operating system has a driver that controls the above features so that application developers don’t need (and can’t!) to communicate directly with the graphics card. You will only work at this level if you are writing drivers, operating systems, or if using some more primitive system, such as MS-DOS.
3. Again the operating system (OS) shall have a interface for application programming (API) for access to what the driver has implemented, with syscalls (system calls). Syscalls can be in Assembly itself or can be made available in a library format for a higher level language such as C.
4. A higher-level library can still further abstract the task, providing a new, friendlier API that can be used in the same way across multiple languages and operating systems.

And then, how to create a graphical library "from scratch"? Depends on where you put the zero.

If you have only one board and one processor, you will start from step 2, writing drivers and operating systems.

If you have a board, a processor, and also an operating system, you will start from step 3, using the features that the operating system offers and building upon that.

The case I imagine you want to know is the latter, when you already have the operating system but can’t understand how libraries like Qt, GTK+, and SDL do to draw on the screen. The answer then is: they take the responsibility to speak to the operating system in its "language", whatever it is (Win32? GDI+? Directx? Opengl? Xlib? Wayland? Syscalls direct to the operating system kernel?).

The C language, for historical reasons, provides a unified way (<stdio. h>) to deal with text files (including the screen and keyboard there), but does not provide the same for graphics. In the background the two cases pass through similar layers (library for the application programmer, API of the OS, driver, bits and bytes for the communication with the components of the computer, until arriving at the level of the electric current that makes everything work).

So it’s very common to have a library, which calls another library, which calls another library, which calls a function dependent on the operating system, which calls the driver, which makes the pixel appear on the screen. We can compare it with opening files in C++ where there are several ways: iostream (C++ default), fopen (C standard), open (POSIX standard), Createfile (Win32) (the first two are higher level and the last two are lower level).

Look at these examples:

1. The application uses wxWidgets on Linux, which calls
2. GTK+, who uses...
3. Cairo to make 2D graphics that...
4. will do the necessary to generate the graphics in the operating system using Xlib, XCB, Quartz, or Win32...
5. that will access the OS with a syscall
6. and OS will use the video driver to send pixels to the screen.

In the case of Windows, you need to pass an option to the compiler or to Linker to use "Subsystem windows" and thus avoid the appearance of that command line black screen. But failing to do this does not prevent the program from creating windows on Windows (with Createwindowex or any equivalent function), it would only get uglier for the user.

Note that the programmer could also use GTK+ directly if he thought that wxWidgets is not offering any advantage. But if you go down to Xlib (or XCB), you would certainly have more difficulty porting the app to Windows, or when X becomes obsolete and everyone uses Wayland. And I may have missed some layer on the list above! For example, writing this answer I discovered the existence of XCB as an alternative to Xlib.

Or else:

1. A game in SDL
2. that will use calls to Apis Win32 and Direct3d for graphics on Windows
3. or Cocoa and Opengl for graphics on Mac OS.

Remembering that for 3D graphics the programmer can use Direct3d (Directx) and Opengl directly, if you prefer. More recently, the Vulkan as an alternative to Opengl.

Not to mention Android and iOS, which must have their own Apis, such as Opengl ES.

In the midst of so many, it can be difficult to know which library is the basis of the others and which are just abstractions. So if you look at the links above to wxWidgets, GTK, Cairo and SDL, you can see that I tried to put the link precisely to the page that explains on what basis the library is built.

Answer 2

I’m a little rusty with this but I guess it’s still that way:

#include <graphics.h>

int main() {
   initgraph();
   //faz alguma coisa aqui
   closegraph();
}

I put in the Github for future reference.

See the available functions to make the drawings. I just don’t remember if this is standard or need some specific library.

remembering that this is for a console application. If you are going to do it on a system with its own screen system, you will have to use the operating system API.

Another possibility is to access the graphics card more directly. You have to read its documentation. Not that people usually do this, but it is a possibility. In some cases just write in the graphical memory. This is the way to create a graphical library from scratch. Nobody does this. Nobody recommends this. It’s the same as saying you’ll make the operating system because you don’t want to use the system calls existing.

Other than that, the question is very broad. No one gets away from the total lack of awareness of how they begin to do something so complex. So to answer would have to write a book (which by the way I don’t think exists)

Answer 3

To put it in perspective: no language is inherently "graphic" or "text". At some point, there needs to be an initialization so that the program is not blind, deaf and dumb. Such preparation may be done by the programme itself, or by the loading process that precedes it.

In the case of C, at least in UNIX/Linux, the loading process prepares the ground by delivering the already opened text terminal (stdin/stdout/stderr).

Such a program can run in graphical mode, but you have to invoke a graphical library explicitly to "go into graphical mode". On Linux there are numerous libraries to choose from: GTK+, Qt (for C++), Enlightenment, SDL, etc. The system does not impose a specific library.

In the case of SDL, everything starts by calling the Sdl_init function().

From then on, each library has its own set of methods or functions to handle graphic primitives (pixels, geometry, rendering text, etc.)