Re: What does your OS look like? (Screen Shots..)
Posted: Wed Aug 10, 2016 2:10 am
Finally implemented simple paging. New initialization screen that shows if there are any failures and if everything has loaded correctly.
The Place to Start for Operating System Developers
http://f.osdev.org/
pdurlej wrote:
This screenshot looks very interesting. Reminds me a bit of old Windows.pdurlej wrote:
Nope, it's a 640 x 480, 32-bit color:glauxosdever wrote:Hi,
pdurlej wrote:It is some VGA mode?
Amazing work! You should crank up that resolution a bit. Tell us more about your compositor. Does it have double buffer, alpha blending etc?pdurlej wrote:Nope, it's a 640 x 480, 32-bit color:glauxosdever wrote:Hi,
pdurlej wrote:It is some VGA mode?
The OS is capable of running in 16-color modes, though:
Desktop with apps:
Same apps, different UI theme:
octacone wrote:Amazing work! You should crank up that resolution a bit.
While Nameless OS used to tripple buffer windows and do alpha blending, currently it does not.octacone wrote:Tell us more about your compositor. Does it have double buffer, alpha blending etc?
Looks amazing, great job.pdurlej wrote:... Nameless OS ...
Awesome! Really interesting design choice. Well done, it looks beautiful + efficient.pdurlej wrote:octacone wrote:Amazing work! You should crank up that resolution a bit.
While Nameless OS used to tripple buffer windows and do alpha blending, currently it does not.octacone wrote:Tell us more about your compositor. Does it have double buffer, alpha blending etc?
In the current version, there is usually a single framebuffer.
Also there is a low-level window manager in the kernel and an userspace widget library.
Firstly, the userspace requests the window manager to create/destroy/move/raise windows.
When a portion of screen needs to be repainted, for example a window is closed, resized or moved, the window manager automatically determines which regions of which windows need updating. Then, the kernel sends appropriate messages to the processes involved.
The userspace processes then respond to the messages by requesting the window manager to draw graphics primitives such as a rectangle of specific color at a specific position, an image, a text, etc. The window manager automatically does clipping, when a window is partially obscured or off-screen.
The userspace can also call graphics primitives on it's own, without a redraw request from the window manager. This normally occurs when something changes in an app, for example a program running inside a command line window prints a message.
Contrary to the low-level window manager, window decorations and widgets are implemented in the Nameless OS standard library. The library handles incoming messages and responds with window manager calls.
For example, when the user pushes a mouse button in a window, a message is sent to a process that created the window. The library receives and handles the message. If a button is clicked, the library calls graphics primitives to draw a depressed button.
Screen contents are not double buffered or copied unless a window is moved, or a portion of screen is scrolled.
Lack of double/tripple buffering conserves both CPU time and memory, while the split between the simple in-kernel low-level window manager and the more complex userspace library makes the system more robust.
Why not port freetype2? It's much easier than it sounds.Roman wrote:Why don't you just write a bitmap font parser for an existing format?