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. When the RAM is full Haiku will utilize the hard disk as an additional backing store.
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. While we’d like to change this for the future, Intel introduced a functionality called write-combining in something like 1998 that is supposed to optimize write access to something like a frame buffer. Instead of directly writing the bytes back to the buffer instantly, the CPU waits until you have written 32 sequential bytes, and then writes them back at once, in a single burst. Enabling write-combining is therefore even a good idea if you already have a optimized your graphics output, although the effect is less noticeable in that case.
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.
While the original idea of having a common base class sounds nice, it doesn’t work out in reality. RootLayer used to be the mother of everything, and hence, was a quite bloated piece of code. When you moved a window, the RootLayer would have locked the screen, and then computed the new clipping for all affected layers on the screen, updated the window borders (Decorators), and triggered a redraw of the BViews. During that time, no other window could draw on the screen. When you moved a window around the screen, you would have been able to experience lots of frame drops in a window playing some video (if that would have worked yet :-)).
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. When you install a new font, you have to launch the Fonts preferences application, and press its “Rescan” button. And while you’re at it, you can also specify the amount of memory the app_server uses for font caching.
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. When you switch between workspaces the position and order of the windows is usually preserved. There are exceptions when it comes to windows that are visible on multiple workspaces, but I never quite understood why this is and how it is working. Adi Oanca has implemented a similar behaviour for the Haiku app_server, and I hope that he figured out how it worked or even found a better way how these windows are handled.
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 (?) computer experience, but the Desktop as the app_server manages it. Every user logged into your system will get a different Desktop object. Every user? Well, for now, this is just you - but the app_server can manage as many desktops as needed. If you notice this for R1 remains yet to be seen, but the chances for this are not too bad.
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-)). Somehow we assumed that FreeType was safe to be used in a multi-threaded environment. It even kind of is, but not in the way we used it.
FreeType provides an FT_Face object for every font face you are using - these objects are completely separated and can be used from different threads without worries. You just can’t share one of these objects between several threads, and that’s exactly what we were doing. Of course, that was a more or less stupid oversight on our behalf. But it’s also a major pain that FreeType simply doesn’t allow you to access a font face in a shared manner - it gives you a very easy to use API, but also a very limited one.
We just started discussing this topic in the app_server mailing list, so I don’t know yet to what conclusion we’ll come. We will probably need to introduce another abstraction layer between FreeType and our font sub-system, so that we can efficiently use FreeType without being locked in its single threaded design. Right now, I’ve introduced a per font face lock that might not even cover all uses of the object, but greatly lifts the situation.
If you know FreeType well, and feel that I missed something looking at the API it provides, feel free to tell me :-)
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? Not true, as the inter-CPU messages (which are interrupt based) are still working. But even the APIC timers don’t trigger an interrupt anymore (the timer interrupt is what makes the CPU switch to another thread from time to time).
So both processors are running the thread they were given at some point. Sometimes they went through until the disk manager is trying to read something from a disk (as you need interrupts for that), sometimes they hang before - probably depending on which CPU gets which thread. The page daemon for example, isn’t likely to get us that far :-)
Anyway, the APICs are correctly initialized and enabled - the only thing that I still don’t touch is the I/O APIC which is responsible for dispatching interrupts to the local CPU APICs. But since it’s working fine in a uni-processor environment, it should also just work with both CPUs running.
So even though Hyper Threading seems to be popular, I am postponing it a bit - it would definitely take some more time to get right. I’ll probably tackle it again when the system doesn’t use the virtual wire mode anymore for SMP (in a few weeks, I’d guess). Also, to really configure the system correctly, we should look at ACPI which isn’t available in the boot loader right now.
If you want to give it a try yourself, Hyper Threading is currently disabled: to enable it, you’d have to uncomment lines 228 to 231 in src/system/boot/platform/bios_ia32/smp.cpp. But don’t get your hopes up too much :-)
Now, it’s app_server time.
