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 (?
As many of you know, we are using FreeType as our font renderer. It is already able to produce very nice font renderings, but the quality of the rendering still seem to improve with every further version.
Until today, we were using FreeType in a wrong way, though. That didn’t affect the rendering quality, but let the app_server crash pretty regularly (note, it still does that, but for different reasons and even a tiny bit less often 8-)).
As I advertised yesterday, I had a short look at hyper threading today. Well, that short look was actually a bit longer than what I hoped for - and it even still doesn’t work.
While starting up the second logical processor is working almost fine - for some reason it needs some longer timeouts between the initialization commands - I get no interrupts anymore, when both processors are running. Have I said none?
Tomorrow, I’ll have a short look at implementing Hyper Threading support - not the full monty, but it would still be nice to have it start using the two logical processors in my system; after all, I bought this system with enabling Hyper Threading in Haiku in mind.
After that excursion, I will start looking at the app_server again. I had started to refactor the code some weeks ago, but got interrupted, and didn’t find the time to continue this effort.
I just booted into Haiku working on an SMP machine. Unfortunately, I am not really sure what change exactly triggered this - I’ve tried so much and all of a sudden it started to work, after I disabled setting up the APIC (the advanced programmable interrupt controller) to use ExtINT delivery mode - that shouldn’t tell you anything, I know, but it’s still remarkably that this code was originally disabled as well.
Even though I usually don’t work at the weekend, I had to, since I didn’t manage to work 8 hours on friday.
Unfortunately, I still haven’t got SMP to work yet. I’ve investigated the issue, and came to the simple conclusion that the APIC interrupts doesn’t reach their goal (it just took me some time to get there, and exlude all other possible faults). I can trigger such an interrupt manually, so the second CPU is setup correctly, but its APIC doesn’t seem to be.
