OSDev.org

Posted: **Fri Aug 19, 2016 12:36 am**

omarrx024 wrote:Exception handlers look like this. I still need to implement task termination, so that when the fault originated in userspace and not in kernel-space, I just terminate the faulting process instead of halting the system.

At least you have a working compositor.

Really cool looking crash log, I think you should make a panic screen out of it.
What font is that?

Posted: **Fri Aug 19, 2016 2:40 am**

octacone wrote:
omarrx024 wrote:Exception handlers look like this. I still need to implement task termination, so that when the fault originated in userspace and not in kernel-space, I just terminate the faulting process instead of halting the system.
At least you have a working compositor.
Really cool looking crash log, I think you should make a panic screen out of it.
What font is that?

It's Alotware's font, by Muazzam here in the forums. It's in public domain and in my GitHub repository if you'd like it: kernel/fonts/alotware.bin.

Posted: **Fri Aug 19, 2016 6:02 am**

Implemented a PNG parser, now I support bmp (16, 24 and 32 bit), jpeg and all png formats.
Also implemented transparency.
The picture on the desktop was created using this code:

Code: Select all

//Picturebox
#define PB_ORIGINAL		0
#define PB_CENTERED		1
#define PB_STRETCH			2
#define PB_TILED			3
#define PB_ALIGNED			4

//WControl *ctrl_create_picturebox(CWindow *pWindow, int x, int y, int w, int h, char *szPath, uint32_t backcol, uint32_t mode)
ctrl_create_picturebox(pWindow, 50, 50, 800, 800, "B:\\DATA\\PICTURES\\test2.png", COL_TRANSLUCENT, PB_ORIGINAL);

Thats my first real GUI control element, I will add buttons etc soon
The background itself is a jpeg file which gets loaded depending on the resolution of the screen.
This way I can still scale up the pictures for unsupported resolutions, but support most resolutions with best quality available.

Original PNG picture: https://upload.wikimedia.org/wikipedia/ ... tion_1.png

Posted: **Fri Aug 19, 2016 6:40 am**

Ch4ozz wrote:

That is fantastic! Btw, why do your screenshots look so downscaled?

Posted: **Fri Aug 19, 2016 6:46 am**

octacone wrote:That is fantastic! Btw, why do your screenshots look so downscaled?

Im on a laptop and have my GUI on 125% size.
Also imgur compresses the screenshots to jpg

Posted: **Fri Aug 19, 2016 6:47 am**

Ch4ozz wrote:
octacone wrote:That is fantastic! Btw, why do your screenshots look so downscaled?
Im on a laptop and have my GUI on 120% size.
Also imgur compresses the screenshots to jpg

Just post it using forum. lol.

Posted: **Fri Aug 19, 2016 12:20 pm**

Thanks to the new canvas implementation, the Terminal in Ghost can now be started within the user interface

Here's a video of it running: https://ghostkernel.org/files/ghost-0.5 ... minal.webm

It's still a little buggy but i'll fix that soon

Some things to mention about this, because Ghost is a pure microkernel based OS (implementing that with an in-kernel window server would have been way easier):

each terminal is runs in its own process
terminals create their own UI by asking the window server for a window + a canvas for painting
the window server runs fully in userspace
the character painting is done by the terminal through a shared memory region (a canvas) that is then painted by the window server

Posted: **Fri Aug 19, 2016 1:24 pm**

max wrote:Thanks to the new canvas implementation, the Terminal in Ghost can now be started within the user interface

Here's a video of it running: https://ghostkernel.org/files/ghost-0.5 ... minal.webm

It's still a little buggy but i'll fix that soon

Some things to mention about this, because Ghost is a pure microkernel based OS (implementing that with an in-kernel window server would have been way easier):
each terminal is runs in its own process

terminals create their own UI by asking the window server for a window + a canvas for painting

the window server runs fully in userspace

the character painting is done by the terminal through a shared memory region (a canvas) that is then painted by the window server

How did you get the windows transparent while keeping such a smooth dragging speed?
My dragging is only smooth when using SSE memcpy, doing alpha calculations makes it much slower because I have to read every single byte for it.
Looks pretty good!

Posted: **Fri Aug 19, 2016 1:58 pm**

Ch4ozz wrote:How did you get the windows transparent while keeping such a smooth dragging speed?
My dragging is only smooth when using SSE memcpy, doing alpha calculations makes it much slower because I have to read every single byte for it.
Looks pretty good!

I've ported cairographics, because as you have found out by yourself it's very hard to write well-performing pixel manipulation code.

Also you'll come to the point where you want proper font rendering and shapes etc., that's what cairo provides. Cairo uses the pixman lib for it's transparency calculations which then makes full use of SSE/SSE2 instructions for performance.

What you should also do: Keep your entire screen in an normal-memory buffer and copy only parts that have changed to the VESA framebuffer. Reading/writing the vesa buffer is very slow so avoid it as good as you can.

Edit: Oh, and if your keen to write your own graphics library, why not use SSE instructions for your transparency calculations? Once you do this and no more read from the framebuffer, you'll be fine.

Posted: **Fri Aug 19, 2016 2:30 pm**

max wrote:
Ch4ozz wrote:How did you get the windows transparent while keeping such a smooth dragging speed?
My dragging is only smooth when using SSE memcpy, doing alpha calculations makes it much slower because I have to read every single byte for it.
Looks pretty good!
I've ported cairographics, because as you have found out by yourself it's very hard to write well-performing pixel manipulation code. Also you'll come to the point where you want proper font rendering and shapes etc., that's what cairo provides. Cairo uses the pixman lib for it's transparency calculations which then makes full use of SSE/SSE2 instructions for performance.

What you should also do: Keep your entire screen in an normal-memory buffer and copy only parts that have changed to the VESA framebuffer. Reading/writing the vesa buffer is very slow so avoid it as good as you can.

Edit: Oh, and if your keen to write your own graphics library, why not use SSE instructions for your transparency calculations? Once you do this and no more read from the framebuffer, you'll be fine.

Im doing all of this just without SSE instructions

Im not that good with SSE and MMX commands, but Im about to learn it at the moment

Thanks for the tips, might gonna check out the lib

Posted: **Fri Aug 19, 2016 2:37 pm**

Looks great. Seems you made some good progress today.

Posted: **Fri Aug 19, 2016 4:50 pm**

Ch4ozz wrote:Im doing all of this just without SSE instructions
Im not that good with SSE and MMX commands, but Im about to learn it at the moment
Thanks for the tips, might gonna check out the lib

Just in case you're not aware of it, MMX is deprecated now, and newer CPUs even support AVX alongside SSE.
Nice work max, BTW!

Posted: **Sat Aug 20, 2016 12:25 am**

max wrote:Thanks to the new canvas implementation, the Terminal in Ghost can now be started within the user interface

Here's a video of it running: https://ghostkernel.org/files/ghost-0.5 ... minal.webm

It's still a little buggy but i'll fix that soon

Some things to mention about this, because Ghost is a pure microkernel based OS (implementing that with an in-kernel window server would have been way easier):

each terminal is runs in its own process
terminals create their own UI by asking the window server for a window + a canvas for painting
the window server runs fully in userspace
the character painting is done by the terminal through a shared memory region (a canvas) that is then painted by the window server

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?

Posted: **Sat Aug 20, 2016 2:55 am**

Doesn't look like much new, but performance is much better in my OS now that I have an SSE2 memcpy and SSE2 alpha blending, which works on 4 pixels in one operation; as compared to my old routine which did pixel by pixel. For now, it uses unaligned-SSE2 instructions for working with the VESA back buffer in RAM. I'll fix this soon; to let it use aligned instructions when possible, and perhaps gain a little more performance.

Posted: **Sat Aug 20, 2016 3:24 am**

It's certainly not the most interesting thing here by a long shot, but my kernel can now produce stack traces whenever it crashes. I've put in an artificial double free in the main method to trigger a crash, however it should make debugging in general a lot easier

OSDev.org

What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)

Re: What does your OS look like? (Screen Shots..)