OSDev.org

Unsure if this has been asked before but I'm just curious, will a modern os deal with graphics the same way my hobby os would?

The only way that I know how to do graphics is to write image data to a section in memory specified by multiboot that then gets displayed on the screen. Does, say windows or linux, also do this? or is there a more complex way of doing it?

Also I'm guessing that usually a graphics card is utilized too? Writing to a buffer on the card rather than in the memory

If anyone can enlighten me I'd appreciate that

Danny

It's clear that a modern OS abstracts graphic through multiple layers. first the drivers that could be VGA, VBE, or an acculatored (spelled right?) graphic card driver. then a low level drawing interface (like gdi on windows) and then a widget library (like gtk or qt) on top of it. everything you see are graphic files (wallpaper .jpg, cursor .cur, Icons .png or .ico, status bars .bmp or .jpg, ...) that are decoded and drawn by these libraries.

EDIT: GDI has functions to draw rectangle, line, circle, ...but not widget and controls like button, ... so it's not too low level.

dannywrayuk wrote:Unsure if this has been asked before but I'm just curious, will a modern os deal with graphics the same way my hobby os would?

Unlikely.

dannywrayuk wrote:The only way that I know how to do graphics is to write image data to a section in memory specified by multiboot that then gets displayed on the screen. Does, say windows or linux, also do this?

Well, without anything special, the Linux framebuffer uses the same framebuffer as you. However this is not true for X, or when there's an fb driver in the kernel for the card, only if it fallbacks to vesa compatible frame buffer console.

dannywrayuk wrote:or is there a more complex way of doing it?

Actually, there are more ways (in plural) and all of them are pretty complex.

dannywrayuk wrote:Also I'm guessing that usually a graphics card is utilized too? Writing to a buffer on the card rather than in the memory

You are mistaken here, you're not writing to conventional memory. The framebuffer area is an MMIO area (memory mapped input-output), meaning you are using a buffer on the card when you write to it.

dannywrayuk wrote:If anyone can enlighten me I'd appreciate that

Danny

In general it's difficult, because there are so many ways. Windows has one (the low-level GDI as mmdmine mentioned), MacOSX has another, and under Linux, you have several.

But in a nutshell, a video card driver is responsible of switching resolutions and returning a framebuffer address. It is safe to say this is common to all cards and drivers. Most cards also provide a fast video to video memory copier function, called blitter, and most of them can manage multiple frame buffers at once. They also may provide 3D, that is, generating the content of the framebuffer on hardware (and for that, there are - again - many ways: DirectX, OpenGL, Vulkan etc.). What's common here, is that you feed the GPU with 3D data (called vertex buffers) and it translates those into 2D (using vertex shaders). Then you also provide colors and textures, light directions, colors etc. and the GPU outputs the contents into a framebuffer for you (using fragment shaders). The output buffer can be in conventional memory (off-screen rendering) and can be a framebuffer (MMIO, on-screen rendering). Note this is a very very simplified description.

These has nothing to do with the higher-level libraries, like widgets, buttons (Motif, GTK, QT, wxWidgets and big part of GDI) etc. That's a totally separated layer above all of this.

For further reading:
https://www.kernel.org/doc/html/latest/fb/index.html about frame buffers and fb drivers in Linux (used by consoles)
https://coggle.it/diagram/WqZQRNMJtIsoh ... x-graphics the Direct Rendering Manager (used by X and Wayland)
http://dri.sourceforge.net/doc/drm_low_level.html more on DRM
oh, almost forgot: Direct Rendering Interface on wikipedia is surprisingly accurate and has figures for better understanding how the frame buffer(s), DRM, DDX and all the other fits together.

Cheers,
bzt

bzt wrote:These has nothing to do with the higher-level libraries, like widgets, buttons (Motif, GTK, QT, wxWidgets and big part of GDI) etc. That's a totally separated layer above all of this.

Apropos that topic, which as bzt says is somewhat separate from the low-level concerns, some time back (three years, wow, tempus fugit), I started writing a wiki page entitled Graphics stack, which is meant to give an overview of the layering used by most modern video systems, and some of the options and alternatives for how it can be done. The page needs a lot of work, but you may still find it helpful in trying to understand what parts usually go where.

There's no requirement to follow this sort of stack layering in your design, and quite a few here don't (or don't think to, or try not to and don't get very far, or... you get the idea), but most find it a useful way to organize their system, and it is what all of the 'big' PC operating systems use so it is at least useful information (or would be if I ever finished it, I suppose).

And yes, I would like to take this time to solicit help on that page from others here, since I was quite a bit out of my depth when I tried to tackle the topic.

EDIT: I just did a little clean-up on the page in question, so long-time members may want to check that out.

Hah, I've missed that wiki page. I've checked it now, and it is pretty good, thanks Schol-R-LEA! Good job!

Cheers,
bzt