Hi, this is my 2nd post on the forum, and thankyou to those that helped me on the first one, i really appreciate it

Anyway, i've been wondering about this a lot, and i guess it's just one of those things where i've "information knocked into my head" in regards to how the CPU executes instructions one at a time, linearly.

Because i know this i don't really have the aptitude to grasp just how say, a game is able to render it's 3D world without hanging, what do i mean by this?

Because i understand everything executed in the program is handled 1 instruction at a time and those instructions are executed sequentially, that means that while the CPU is busy doing something, it can't do something else.

I am aware that the OS has "time slices" that it allocates to whatever is currently running on the system, giving it a dedicated amount of time to complete a task or part of it, before giving time to the next process or application.

I also know that we're talking nanoseconds or milliseconds of execution which is not perceivable by us, but because this is happening millions if not billions of times per second it "looks" like the feedback is instantaneous and motion is very fluid.

You see, i just got into the realm of WM_PAINT messaging, using very basic GDI to draw text onto a window, but what i am unsure of is does "Painting" also mean 3D geometry in a 3D worldspace? because from my point of view, you get a WM_PAINT message, then process it based on how you want it handled, before returning to the message queue.

Are you just feeding the message queue colour co-ordinates that saturates the entire screen? and that's how painting is handled?

Again i am thinking this in a purely "step by step" order of execution because of how instructions are actually executed, so it is very hard for me to visualize in my head how it's able to produce what i just explained even though it's drawing the screen so fast i wouldn't be able to notice that step by step execution is the case, but i'm still stuck there in my head.

Does that make any sense? And how does this work if you want to interface with a Graphics API like OpenGL or Vulcan? Are you just passing GPU information to a device context?

I'm still very new to this but i'm still learning, I want to make a GUI application snake clone or something else but i just have a hard time visualizing it in my head.

If the system has a graphic card, and the GPU driver is installed and working, then WM_PAINT will be converted to GPU primitives, and passed to the GPU, which then draws the objects to graphics memory.

But it doesn't have to be that way. Before GPUs, the CPU would do the work and write pixels to graphics memory, one-by-one.

Interfaces like OpenGL et. al. are just more efficient ways to get data to the GPU. WM_PAINT will still get there, but it isn't well optimised for GPU tasks.

The system scheduler works slightly differently than you describe. It allocates time slices only to currently active threads, not to everyone. If you have 100 applications on the taskbar, and your application's window is in the foreground, the scheduler won't allocate time to those 100 applications, as they are considered inactive (not doing anything). Only the foreground window will consume all the processor resources, while the rest will remain in a waiting queue. As soon as you activate another window, the scheduler will switch to it.

It's a different matter when you have several tasks running concurrently—for example, you're typing in MS Word while an MP3 player is playing in the background, or a long data copy is in progress. Only then will you share the CPU resources among three.

However, task priorities also need to be taken into account here—processes with a higher priority (for example, the system task manager) can take your allocated time without queuing.

So, when you launch a game that fills the entire screen, CPU time is dedicated exclusively to it, which facilitates fast graphics rendering (when there's no GPU), as no one else is competing for your allotted time. Data is copied to video memory in blocks of several megabytes at a time, so lags are less noticeable.

So when you get that message, and it gets converted to a GPU primitive, how would you take that information and then branch off of it to render the "desired" picture you're trying to display?

For example, if i had two panels, with one showing on the screen as red, and another as blue, but only one could be displayed at a time, how would the WM_PAINT message be interpreted to display the correct panel when i want it to?

I think about this more akin to rotating a camera in a game, where the screen will display everything around you. But how does the display know what to display for each pixel on your screen as you turn because it will have to be updated, so how do you account for something if you don't know how it's going to look ahead of time?

I will say, your comment was helpful, but maybe the topic is still too advanced for me.

Each program will decide for itself what it wants to draw. The OS doesn't know what to do. So each program will just draw a new scene when it wants to show something new. Programs can use WM_PAINT, or use OpenGL, or whatever method makes sense, and tell the OS to draw new things in its window.

If both panels occupy the same area, say, (0;0;100;100), then it will turn into the same sequence for display rectangle on the screen. Only the color attribute will be variable, depending on the number of the panel that is visible at the moment of redrawing the window (WM_PAINT).

But at the end of the current WM_PAINT, the system will receive instructions for only one visible panel to fill the rectangle with the appropriate color. Moreover. The rectangle itself will not draw immediately, but when the system reaches the playback of these primitives in video memory. Until then, the WM_PAINT result will be saved as the need to fill the specified area on the screen with the color specified by the program.

Ah okay, that makes more sense, thankyou.

Is there any resources you recommend for reading? I suppose maybe Game Engine architecture might be a good start but i will need to put that off until i've finished Petzolds book Programming Windows.

I imagine i can just read the OpenGL documentation or whatever i decide to use and translate it to assembly.

Also i really appreciate how helpful you guys are, it means a lot.

Today CPU has few cores.
It means that you can write code to assign a code flow (a thread #1) to a core #1, and thread #2 to a core #2.
So, in theory, there is no 'slicing' in this case --- two CPU instructions from two threads may be executed at EXACTLY same CPU instant of time.

As for WM_PAINT --- this message has a very low priority, and Windows will send it only when there are no other messages in queue.
If you are planning to code a game in Windows, you will need to use threads.
You can also use timers, but the timers have low resolution and may not be suitable for a fast running game.

When you draw in response to WM_PAINT, you must use the, so called, "double buffering". It means, you draw not into HDC from WM_PAINT message,
but into HDC created as a bitmap, so basically, you paint into memory, way faster than to screen. When your image in memory is ready,
you dump it into screen (HDC from WM_PAINT message) in one shot, a very fast operation.

This is a good set of tutorials to reference written in .c
https://winprog.org/tutorial/