Windowing

Universal Aspects of Window Systems

A World Without Windows?

Showing images on a screen is fundamentally important. This importance stems from the fact that since the 1980s, it has become evident that interacting with programs through a graphical user interface (GUI) is typically more efficient than using command-line interfaces. The frustration of generating images without the capability to see them is considerable. Many of you, belonging to the Millennial and Gen Z generations, may not have experienced this directly, but pioneers in computer-generated imagery (CGI) often had to work on images without the ability to interact with them on a screen in real time. Much of the early image processing software was operated via command lines without any graphical interface. Understanding how to display images on your screen is very beneficial when working with images. As we delve deeper into CGI techniques, being able to see and interact with what our programs are creating becomes increasingly valuable. However, there are a couple of points to note:

• The process might seem daunting, but it's more accessible than one might think.

• Despite its importance, finding resources on this subject can be challenging, as it is often overlooked, even though there are some quality tutorials and introductions available, particularly in materials covering real-time graphics APIs like DirectX.

The scarcity of educational resources on this topic can be attributed to a few factors, often not discussed or overlooked by educators:

• It is sometimes viewed by academics as a skill without inherent value, one that students can learn independently, which is a misconception.

• It's dependent on the operating system. The methods for displaying content, particularly images, vary significantly across Windows, MacOS, Linux, and other systems. Even within a single system like Linux, there are multiple approaches, though the underlying concepts are largely the same.

• It's seen as complex. This often involves understanding the native mechanisms of operating systems and working with relatively low-level libraries, which is thought to require years of experience. This is partially (un)-true.

This situation has a couple of implications:

1. To meet everyone's needs, we would have to teach how to create and display images on Windows, Mac, Linux, etc., which triples the workload compared to using a unified API. Given our limited resources, we'll initially focus on Windows, where a significant majority of you work. However, rest assured, we'll explore Mac and Linux basics later on.

2. Many might suggest (often professionals who may seem not to want you to succeed) using existing libraries like Qt. While Qt itself isn't inherently problematic, it does have significant drawbacks. It's a vast library with peculiarities, such as a special pre-compiling step that converts unique syntax in your code into C++ code that the compiler can use, centered around a concept of "slot" that Qt heavily relies on, among others. Though learning Qt is an option, we will not cover it here. The main advantage of using a library like Qt is its cross-OS compatibility, but we'll demonstrate how to manage without it—and yes, it's entirely possible to do so.

3. Alternatives to Qt, such as GLFW, offer a simpler solution for addressing cross-OS windowing issues. Despite GLFW's popularity and ease of integration, it has its limitations, which might lead you back to native windowing systems. Hence, learning the native approach from the outset is beneficial. As you'll discover, understanding and compiling the code for windowing is not as daunting as it seems, especially given its brevity.

4. For illustrating how to build 3D apps with windows, a real-time graphics API might seem suitable. However, with the current state of 3D graphics APIs, where OpenGL is becoming obsolete and alternatives like DirectX and Vulkan (for Windows - and Metal for Mac) are complex, fitting this into a brief format becomes challenging. Instead, our lessons will start with displaying a ray-traced triangle in a window, avoiding the need for a real-time graphics API. This unconventional approach will bypass the complexity of extensive preliminary lessons on graphics APIs.

5. Did I say it was fun. Well for a nerd it is.

With that in mind, let's dive in.

Universal Aspects of Window Systems Across Different Operating Systems

Before diving into the practical aspects, it's essential to grasp that all window systems operate on similar principles. Beyond the mere appearance of the window, what we're addressing here is the interaction mechanism between your program and its users. This encompasses not just the window itself but also input devices like the mouse and keyboard.

Here's a simplified breakdown of how it works:

• First, you initialize a window, setting basic properties such as its size and title.

• Next, you make the window visible.

• Then, an interesting process begins. Your program starts to respond to inputs. Most commonly, these inputs come from the mouse and keyboard. Your windowed application enters an infinite event loop, listening for events where an event could be an action from the mouse or keyboard. When you move the mouse or press a key, the operating system detects this action and forwards it to your application's event loop, effectively saying, "Here's an event triggered by the user." Your program, through functions provided by the OS's API, receives the event data (e.g., new mouse position, key pressed) and reacts accordingly. This interaction is how you and your computer communicate.

In pseudocode, this interaction process might look something like this:

void MyWindowProcFunc(WindowHandle handle, Message msg, SomeParams params) {
    switch (msg) {
        case MOUSEMOVE:
            int x = ConvertParamsToInt(params[0]);
            int y = ConvertParamsToInt(params[1]);
            // Handle mouse movement
            break;
        case LEFTBUTTON:
            // Handle left mouse button press/release
            break;
        ...
    }
}

WindowHandle CreateWindow(...) {
	WindowsProperties prop;
	prop.title = "This is My First Window";
	prop.size.width = 640;
	prop.size.height = 480;
	// more props like color, etc.
	...
	prop.identifier = MY_WINDOW_ID;
	prop.proc = MyWindowProcFunc;

	WindowHandle handle = CreateWindow(&prop);

	ShowWindow(handle);

	return handle;
}

void DoSomeWork() {
	Render();
	ForceRedraw();
}

int main() {
	CreateWindow(...);
	Message msg;
	while (1) {
		while (MessagesInQueue()) {
			msg = GetMessage(POP_FROM_QUEUE);
			if (msg.value == QUIT)
				break;
			DispatchMessage(msg);
		}
		// Additional tasks, like rendering an image...
		DoSomeWork();
	}

	CleanWindow(handle);
    ...
}

The pseudocode provided is heavily inspired by the Windows operating system's approach to handling window events, but the underlying concepts apply broadly across various systems. Here's an essential aspect to understand: the application runs indefinitely within an infinite loop located in the main() portion of the app. During each iteration of this loop, the application checks for incoming messages. Operating systems typically queue these messages, meaning your application might need to process multiple messages sequentially within a single cycle.

If a message indicating that the application should quit is encountered, the loop is exited, and the program proceeds to clean up any window-related resources. It's also worth noting that when messages are received, they are dispatched, triggering the call to another function, MyWindowProcFunc, which was specified during the window's creation. This function is where you define how to respond to various possible messages, such as mouse movements or clicks, as well as a multitude of other events like draw messages initiated by the OS for window redraws or keyboard actions.

In our example, we focused on mouse movement and the pressing or releasing of the left mouse button. However, numerous other messages could be handled, including those related to redrawing the window after it's been obscured by another window or processing keyboard inputs, among others. This structure allows for a responsive and interactive application, capable of handling a wide array of user inputs and system notifications.

The mention of MY_WINDOW_ID has been omitted here, but it will be discussed in further detail in the subsequent section. This identifier plays a crucial role in the management and interaction with window resources within our application.

Note that after processing events, we have the opportunity to perform additional tasks before looping back to event processing. This cycle eventually continues for event until your decide to quite the application. In our code, these tasks are encapsulated within the DoSomeWork() function. This is where activities such as rendering a 3D scene image or image processing take place. It's also important to signal to the window that we wish to refresh its content with the updated image. This approach is fundamental to creating animations. By generating new frames at regular intervals and requesting the window API to refresh the display, we can animate content. A practical demonstration of this process will be provided in the next chapter.