Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
zesterer wrote: Presumably though it doesn't redraw on *every* update though? You'd end up redrawing a ridiculous number of times. I presume it's capped at something reasonable like 50-60Hz?
I meant, I copy my back buffer to the physical VBE frame buffer. My OS uses VBE to set the graphics modes, and so it has no way of knowing exactly the hardware refresh frequency, but I think 60 Hz is common enough to call standard. It copies the back buffer to the physical buffer whenever the back buffer has been changed, and I already mentioned when that is: whenever the mouse is moved, a window is dragged, or an application requests a redraw.
At the moment, I don't redraw a "ridiculous" number of times, and the performance is actually great on VirtualBox and VMware and OK on real hardware, but I could do some work on it still, to improve on QEMU without KVM.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
It is the job of the window manager to know where every window is and what parts of them need to be updated. You need some way to restrict painting to a region that the window manager will compute using information about the part of a window that is visible and the part that is invalid. That way, you can use your CPU time for other things than silly redraws of the entire screen just because the cursor moved. You can have the cursor as a special case, where the system saves what's underneath it before it is shown, and hides it by restoring the saved pixels. Remember to temporarily hide the cursor when a window is to be updated while the cursor is over it.
prasoc wrote:one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?
Personally, my compositor has two threads: A rendering thread and a control thread. The control thread does all of the input management and talks to the clients. As part of that client communication, it collects screen update regions from clients - a client will tell the server it wants to mark a region of a window as "damaged", and the server will add that to a list. The render thread will combine all of the damage regions since the last screen update (~60Hz; ideally v-synced, but driver support just isn't there) and redraw those regions. Since I have a compositor with transparency, it needs to redraw everything from bottom to top that would fit within the affected regions - this happens in an off-screen buffer first. I then copy the same regions over to video memory.
prasoc wrote:one question however: what is the best way to achieve screen "updates"? do you have a ticker that updates once every 1/60th a second or something?
Personally, my compositor has two threads: A rendering thread and a control thread. The control thread does all of the input management and talks to the clients. As part of that client communication, it collects screen update regions from clients - a client will tell the server it wants to mark a region of a window as "damaged", and the server will add that to a list. The render thread will combine all of the damage regions since the last screen update (~60Hz; ideally v-synced, but driver support just isn't there) and redraw those regions. Since I have a compositor with transparency, it needs to redraw everything from bottom to top that would fit within the affected regions - this happens in an off-screen buffer first. I then copy the same regions over to video memory.
thank you for the detailed reply, I have implemented a front and backbuffer but using memcpy on the full backbuffer every update is exceptionally slow! a separate "dirty" buffer would reduce the memory copy times huuuugely
Will have a look at those tutorials, quickly skimmed the article and it seems perfect for the hobbyist os developer
Also that video of ToaruOS is spectacular - the windowing system is something for me to aim towards
Just a rough template for the interface, but the next thing I'm working on Indigo: a file dialog (in this case just acting as the usual file browser). Decided to go with this because 1) I can get away with this without a keyboard (at least the most barebones functionality) and 2) I better get off with full blown filesystem support instead of the bare minimum currently used to load programs.
On that note, I need to sort out how to deal with file handles (especially how many to allow), since the kernel doesn't have that much memory alloted to itself.
Impressive and really inspiring, guys! I was staring at the thread several days. xD
I wish I could post here something similar, but my project can't even write into the serial port yet.
I am trying to create NT-like OS but as a first subproject of it, I'm working on a UEFI implementation for a couple of machines of two architectures, namely - MIPS and ARM. The OS itself is planned for x86 as well apart from those two. But now I'm messing around with the Beagle Bone Black armv7 SBC writing the first stages of UEFI PI spec (SEC, PEI). And once it is able to talk to the world I'll let you know.)
ANT - NT-like OS for x64 and arm64. efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).
I've made a huge number of changes over the last 48 hours.
- I've added co-operative multi-tasking. Currently, only the VGA render task and the prompt are active
- I've started work on a very simple filesystem manager
- I've totally rewritten my kernel shell. It has tonnes of new features.
- I've generally just improved the look of the whole OS
- Many stability improvements internally
I've made a huge number of changes over the last 48 hours.
- I've added co-operative multi-tasking. Currently, only the VGA render task and the prompt are active
- I've started work on a very simple filesystem manager
- I've totally rewritten my kernel shell. It has tonnes of new features.
- I've generally just improved the look of the whole OS
- Many stability improvements internally
Very, very happy with Tupai at the moment.
It is beautiful! I really like the looks of it.
What is that font called?
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
Sik wrote:Wallpaper support! (though the internals still need some tweaking)
The next work should be on the existing apps now so hopefully you won't have me flooding this thread for a while.
This... I want.
Please port to x86 so I can run this as my daily machine. Be sure not to increase the resolution.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
I think it's amazing how much progress people have made over the years. Going through this thread (and the "when you're OS goes crazy" thread) just shows how far we've gotten.
Unfortunately, my OS is nowhere enough near completion to show here . Soon, though
Everyone should know how to program a computer, because it teaches you how to think! -Steve Jobs
I really like the looks of it. 
. Soon, though