My official employment at Haiku has ended now. I wanted to thank you for all the donations that made this possible. In retrospect, it were pretty busy months for Haiku, I think I have committed over 600 changes during that time, lots of minor ones, of course, but also a few bigger ones.
In case Haiku runs on your system, you should now be at least able to experience uptimes of several hours, depending on what you do, of course :-)
Instead of completing the paging implementation, I got distracted with a couple of crashing bugs that showed up while testing Haiku, and they kept me busy for the last few days. Strangely enough, I could reproduce each bug easily only on different systems.
At least, I could now run Haiku with BitmapDrawing and Pulse in the background for over an hour (after which I shut it down myself). While playing around with it, I found some weird behaviour with the Backgrounds application which I am currently working on.
It’s not that the app_server is ready and polished or anything close - but it’s in an acceptable state. For now, my main focus is back in the kernel, although I’ll come back to the app_server from time to time in the next days and weeks.
I am currently looking into getting paging support for Haiku. That’s the feature you know by the term “virtual memory” or “swapping”. Plain and simple it makes Haiku support more memory than you have installed in your computer.
Sure, you too! Since Stephan made a BDirectWindow based version of our app_server that directly uses the hardware frame buffer and acceleration features, we noticed that it felt much faster there than on real hardware. How could that be?
The reason is actually very simple. Parts of our rendering pipeline like text output isn’t optimized to use 32⁄64-bit memory access - that means it doesn’t make full use of the memory bus.
In the last couple of days, I reworked the workspace and modal/floating window code of the app_server. But that work got interrupted for the weekend: you know, I don’t work on the weekend. Nah, that’s not it. Actually, Stephan Aßmus finished prototyping the new clipping code for the app_server.
That leads to some interesting changes, and should gain a noticeable amount of speed, especially on multi CPU machines. Before, all objects on the screen, and even the screen itself had a common base class (Layer) and were managed by the Layer subclass RootLayer.
You may have noticed that the posts got rare in the last weeks - it’s not that I don’t want to write updates, but while I’m working on the app_server, it’s hard to report the actual progress.
In fact, I completed the new event dispatching system today - it took longer than I thought as I had to work on several different components to make it work. For instance, our current (and soon to be thrown away) BMessage implementation was not able to deliver messages to the preferred handler, it forgot “preferred” and set “none” - the message dispatching code in BLooper/BWindow was written around this “feature”, as if it were given (messages will always get delivered to a looper, and will then be distributed to the looper’s handler objects - a BView is such a handler for a BWindow).
The font stuff is still not completed, but it works good enough to leave it as is for now. Missing is foremost work on the font cache - I haven’t done anything in this regard yet.
In the last days I’ve mostly fixed bugs, and cleaned up things - there are still enough bugs left, but overall things are improving. Next topic I’d like to work on is the event handling in the app_server.
In the last couple of days, I worked mainly on the font sub-system in the app_server. I didn’t think I would spend that much time on it, and I haven’t even touched the FreeType backend other than temporarily fixing threaded access to it, as explained earlier.
On BeOS, when starting up, the app_server will scan the well-known font directories, and makes all fonts it finds and supports available to end-user applications.
Most of us are used to how BeOS handles multiple workspaces: each workspace represents a configuration for the screen, including resolution, colours, and desktop background. The visual appearance, that is UI colours, scroll bar design, etc. is maintained per desktop, though - all workspaces share the same properties in this regard.
It's maybe not so obvious that every workspace also knows which windows are open on it, and in what order they are.
Since it would probably be boring if I just wrote which bugs I fixed in the app_server today, or which function I renamed to make it easier on the eyes, I think I can better use this forum to introduce some app_server concepts, in varying detail, and in small steps.
The first concept I will introduce you to is the Desktop. Not the Desktop you see as part of your daily (?