OSDev.org

As the press officer of Ghost, I have publish the following news: after the failed German takeover, the work on Ghost may be delayed for about 3 months.

Nah, kidding. I'm not related to Ghost in any way except for being franconian, too

no92 wrote:As the press officer of Ghost, I have publish the following news: after the failed German takeover, the work on Ghost may be delayed for about 3 months.

Nah, kidding. I'm not related to Ghost in any way except for being franconian, too

Haha the work on Ghost is indeed delayed, but due to illness, and will be recovered soon. Also, go go and finish your compiler so I can add it to Ghost

That one may take a while - and I do plan to add some runtime routines for reflection, which may make things more complicated.

When I tried this out in QEMU, the mouse was really unresponsive (it updated about once a second). Great work though!

MessiahAndrw wrote:When I tried this out in QEMU, the mouse was really unresponsive (it updated about once a second). Great work though!

I guess performance will be the focus point of the development for the next versions. Thank you for trying it out

max - I came across a similar performance problem when working on my window manager. Mine is a compositing window manager - where each window has its own buffer, and there's also a screen buffer that the window manager draws to before copying it into video memory. This turned out to be very slow in high resolution VESA modes.

Each time I invalidated the screen (such as moving the mouse) it would perform a full redraw, I managed to optimize this by invalidating a specific region on the screen by calling:
invalidate_window_manager(minx, miny, maxx, maxy)

I pass the region to each of my drawing sub-calls - draw_window(minx, miny, maxx, maxy), draw_background(minx, miny, maxx, maxy), and I only copy the parts that lay within the invalidated region. I only copy the invalidated region to video memory. Because only a small part of the screen is updated at a time, I can do some cool things in real time, like dither the 32-bit screen buffer to lower bit depths, and my mouse is still really responsive and fluid!

This is just a simple optimization (took me a couple of hours to implement) I picked up on and I thought I'd share it because it's really simple and helped a lot - I hope it helps you too.

When I eventually support full-screen windows, it'd be possible to copy the full screen window directly into video memory without having to copy it into window manager's buffer first.

Hey MessiahAndrw,
thanks for your post I already do that. I only copy the area that has actually changed to the VESA output buffer. Whats actually slow is (I'm embarrassed of myself ) that each time the window manager does it's repaint, it copies hierarchically: the desktop is copied to the buffer, then all windows are copied, which themself copy each of their components to the buffer, and each component copies its subcomponents. I should have thought about that being slow in the first place, but I thought "hmm memory copying shouldn't be too bad". I think that will speed stuff up quite a lot.
Thank you for your help though ^-^ I'd love to see your windowing system in action too

max wrote:I'd love to see your windowing system in action too

I've put a screenshot of my window manager on the screenshot thread: http://forum.osdev.org/viewtopic.php?f= ... 93#p243393 It's still a work in progress, but one day I hope to have a downloadable image like you (still too buggy and not much to see yet.)