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.
Kevin wrote:Looks great. Seems you made some good progress today.
I did
octacone wrote:That is some nice stuff. I really like the look of Ghost kernel.
One question doe, why does it take that much for the terminal to fill its own back color? I watched the video and saw that you were using VirtualBox (very fast when it comes to GUI rendering), it shouldn't be that long. Also how hard was it to port Cario Graphics? Is it worth it after all? Do you need to have a working compositor when using Cairo or it can be the compositor itself?
Thanks!
It's actually not the graphics stuff here that is causing the lag. In the demo I did a quick-and-dirty way to update the canvas size, that is set its bounds to the window size each time it is repainted, and that is slow that will be done by the window server itself soon.
max wrote:It's actually not the graphics stuff here that is causing the lag. In the demo I did a quick-and-dirty way to update the canvas size, that is set its bounds to the window size each time it is repainted, and that is slow that will be done by the window server itself soon.
Yeah, you just need to update the canvas size whenever the window size changes. So when the window is initially created, if the window is resized programmatically, or if the user resizes the window. For the user resizing the window, it would probably be better to update it when the user completes the resize (releases the mouse button) rather than for each small mouse movement while they're resizing it, otherwise it might be laggy.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:Yeah, you just need to update the canvas size whenever the window size changes. So when the window is initially created, if the window is resized programmatically, or if the user resizes the window. For the user resizing the window, it would probably be better to update it when the user completes the resize (releases the mouse button) rather than for each small mouse movement while they're resizing it, otherwise it might be laggy.
Completing a resize only after the mouse is released is sometimes called "lazy resizing" (you can also do lazy window movement in the same way, but it rarely has the same sort of advantages). I do this in my compositor by displaying a bounding box during the resize action and resizing the window only at the end. Here's an old screenshot; the bounding box aligns to window rotation. e: here's something a bit less dated
onlyonemac wrote:Yeah, you just need to update the canvas size whenever the window size changes. So when the window is initially created, if the window is resized programmatically, or if the user resizes the window. For the user resizing the window, it would probably be better to update it when the user completes the resize (releases the mouse button) rather than for each small mouse movement while they're resizing it, otherwise it might be laggy.
"just" When the canvas size changes and the buffer is not sufficient, the server resizes the buffer, posting an event to the client that there is a new buffer, the client repainting the content, sending an acknowledge-message to the server and the server then switching to the acknowledged buffer.
I thought about doing something like klange said, but I'll first try to see if it goes well like this, too.
Hello everyone! It's been a long while I didn't posted anything here.
It's been also a while I didn't worked on my own OS, but it's still alive and here is a screenshot of it.
Attachments
Obsidian OS - 21/08/2016
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
f2 wrote:Hello everyone! It's been a long while I didn't posted anything here.
It's been also a while I didn't worked on my own OS, but it's still alive and here is a screenshot of it.
I've seen your posts way back in this thread, and I've always been interested in your OS, but your website link has always been dead since I tried it in 2015. Is it still written in assembly? It's nice to see a project can still be alive after such a long time without activity, very inspiring.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
f2 wrote:Hello everyone! It's been a long while I didn't posted anything here.
It's been also a while I didn't worked on my own OS, but it's still alive and here is a screenshot of it.
omarrx024 wrote:I love tweaking my window manager... and I love posting in this thread even more, lol.
You guys are making me envy! Both of you: really cool operating systems, I wish that Basic OS was that good.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
omarrx024 wrote:
I've seen your posts way back in this thread, and I've always been interested in your OS, but your website link has always been dead since I tried it in 2015. Is it still written in assembly? It's nice to see a project can still be alive after such a long time without activity, very inspiring.
Yes, it's still written entirely in assembly. The project evolved a lot, but very slowly. I've added support for APIC (interrupt controller & timer), SATA (read/write), and SMP. However, it's still 32-bit and there's no UEFI support.
I've added a new screenshot of the OS with a different color scheme.
Attachments
Obsidian OS - Switching color schemes.
"Open source seems to embrace the dark side of human nature." - Ville Turjanmaa
That looks pretty nice @max
Gonna add round corners later too
Im about to implement labels to my gui, but before I have to finish my TTF drawing.
I try to use as little libraries as possible, I dont like bloated code in my kernel
Last edited by Ch4ozz on Sun Aug 21, 2016 10:08 am, edited 1 time in total.
that will be done by the window server itself soon.
When the canvas size changes and the buffer is not sufficient, the server resizes the buffer, posting an event to the client that there is a new buffer, the client repainting the content, sending an acknowledge-message to the server and the server then switching to the acknowledged buffer.
