Interview With Adi Oanca, Part I.
Sep 07, 2004 17:25 UTC, by Chris Simmons, Senior Journalist
From the virtualizing department...

Adi Oanca is heavily involved with the Haiku OS project, participating as one of the team leaders of the App/Interface Kit, and a frequent writer to the various Mailing Lists. We had a chance to talk via email about his current and future work with the project, and the first part of our discussion will be presented here, in part one.
 
Without further ado...
 
 
How complete is the app_server?
 
60%. With the possibility of rising that number fast in the next year. We hope in max one year to have an early beta app_server. Who knows, maybe we'll have more.
 
Will there be any added functionality over BeOS R5 or Dano?
 
Our target is to achieve the same functionality as R5's app_server. Once we have archived that we would have the knowledge of this huge system and implementing new features will be both easier and faster! The only feature that I am aware of that is surely to be added in R1 is 32bit cursor images, the rest are reserved for R2. There are some features like multiple monitor support and more color spaces (maybe others too) that might be added to R1, but he have to see if we have the time and power to do that. As with all this team, the challenge is to clone BeOS R5, because once we have done that, we will be experienced enough to start fighting with more popular Operating Systems with our future releases.
 
Describe working with other developers not in person, but via the internet... Has physical distance been a factor in development?
 
Working over the internet is not that bad, though I had some conflicts with Marcus and Ingo.
 
Was my fault with Ingo. That was when I joined this great team, I then managed to understand how to write emails so that we could speak in harmony. :-) One above other, it's not that different if you are in the same building, because as I found out in the past six months, E-mail and Instant Messaging rulez even if you are in one place. :-) Too lazy to go to the other room or get down 2 floors. :-P
 
There are however times when a physical distance of 2 meters would've been just great! There were many times when I wanted DarkWyrm and Gabe beside me. Especially because there is a 7 hours difference between us. In the case of app_server, that sucks, as I send an email today and if I'm not lucky with DW answering when he wakes up (yup, he used/uses to do that), I will have a reply late in the evening or very early in the morning when I'm already sleeping.
 
Working with people in Europe is not that bad, as they usually respond much quicker, that is if they are available, thus the problems can be solved in one day.
 
Can you briefly describe the app_server and how it works?
 
The app_server is a huge user space application. Because it is that big, it has been split in many parts which can be separately developed and tested.
 
These are the main components of app_server:
* drawing engine
* desktop/layer engine
* application engine
 
Along with them come secondary engines:
* font rendering engine (FreeType2)
* a few managers for: bitmaps, cursors, vectorial graphics (BPicture)
 
Each of these is a story for itself. I will try to detail each.
 
Drawing engine:
In your application you use methods like ::DrawCircle(). For you to see a circle on screen, a message (with circle parameters - origin and radius) is sent to the app_server telling it to draw a circle at a specified position. This is where this engine come in. A circle is a collection of points and each of them must be calculated, and that's exactly what a specific method in this engine does - it computes circle points and writes the result in video card's frame buffer. Circle's inner color and patter, edge color and width are a few variables that this engine process in order to have that circle on screen.
 
The same is valuable for lots of drawing instructions that you find in the BView class.
 
At this point, you may begin to wonder: but where's the 2D acceleration? Well, it is there, but it does not offer as much as you think. The features that all video cards have, and which BeOS R5 driver interface uses, are: fill rect with *one* color, blit(copy) from one location of the screen to another, blit with transparency and cursor support. In reality, 2D acceleration for drawing primitives is only used if you are filling a rectangle with a single, solid color, the rest of them are simply drawn point by point.
 
Desktop/Layer engine:
This engine takes care of user input and that all is displayed on screen as it should.
 
In a GUI, the use of overlapping windows is a must and the server must take care that none of these windows draws outside of its borders. That is not an easy task at all, as the server must keep track of every visible surface of a window and allow it to draw only in that region. And we're talking about per pixel restrictions here!
 
For example if you have to draw a circle in a window, and that window is half covered by another the server must clip that circle so that it fits in the visible region of its window. A hard and CPU expensive operation. You may think this is huge overhead for the CPU, but here we are, all GUIs do that and we still have a responsive system, because of a few tricks. :-)
 
For example if you move an window, there is no need to draw all what that window displays, again, at another location. You can simply use the 2D blit hardware function, and copy window's image and then request the application that is beneath it to redraw its context that has just became visible. Same is valuable when resizing a window: redraw just that needs to be redrawn.
 
When double buffering comes into place, another speed increase will occur, because we often might have the image already drawn in an off screen buffer.
 
Application engine:
This is improperly called an engine but for the purpose of explanation of some app_server internals, we will refer it like so.
 
This part is responsible with the reception and handling of client side messages. For the sake of responsiveness, for each user application(BApplication) app_server spawns a thread which will handle all messages sent to app_server from that application from that moment on. This is the main communication channel and through which other objects like BBitmap, BFont, etc. that need server support send their messages. Maybe you have noticed that I haven't mentioned BWindow. Although windows initially send their creation message through this channel, windows are whole different story.
 
What is a window? You would say... a surface on screen. Well, that's how you perceive it. In fact a window is a thread. It does not have anything visible, it is just a "way" to speak to the server. And that is done by sending messages through a port at the end of which waits another server thread especially spawned for this window(thread). This is done because each window has a life of its own, and its actions need to be influenced as few as possible by another windows, and what better way than to use operating system's threads. Multiplexing can be done, but how would it be if a window is processing something and we would need another window to work with?
 
The 1 to 1 thread relation is the one to use.
 
Now, I'd like to clarify what I said above: "a window does not have anything visible". What you see on screen are layers, upon layers, upon layers. A "visible window" is a layer composed of 2 parts: the layer associated with the top most BView object and the window decorator added by the server - of course when requested(usual cases). 
 
There would be many, many things to be said about app_server but I think this is enough for a general idea. Oh, there is one more thing worth to be mentioned. BView is the base class of all interface widgets. It can do a lot of things, but if has 2 main features that make it so special. 1) It is a canvas - it represents surface on which you can draw and 2) it accepts BView children to which it ceases some of it's space. Every BView has a counterpart object inside app_server and that is exactly a layer, and from here comes my above expression: "What you seeon screen are layers, upon layers, upon layers." When you draw in a BView, in fact that instruction is sent to the server and drawn to the visible region of the associated layer.
 
With the last 2 engines I didn't had the chance to work with but I basically know what they do. The font rendering engine simply passes a Unicode string to FreeType 2 engine you all know, and in return you get a bitmap with the properly written string.
 
The other engine is the management engine. This one does a simple job. It allocates memory space for bitmaps, cursors, vectorial graphics and allows sequential access to them. This is done because of 2 reasons: 1) to save memory and communication overhead by sharing it with the application's code and 2) because the application may be done with that resource but the server still is in need for that resource - take the example of an image being dragged.
 
This is a simple description of app_server, you can find a more detailed one in Newsletter 51 made by DarkWyrm: http://haiku-os.org/learn.php?mode=nsl_view&id=51#182
 
Why wait till Haiku R2 for double_buffering?
 
We won't do that. I recently had a talk with Axel in which he was asking me the exact same question. After a few replies we have decided we shall have double buffering in R1. I've sent an email to DarkWyrm with the discussion Axel and I had to have a confirmation that we will do that in R1. He agreed.
 
At first we thought it's better to use video memory for double_buffering, but the current driver interface does not support allocation of bitmaps inside card's memory. So we said: wait for R2 when we can modify the driver interface. I had some talks with Rudolf also, and in more recent emails he said that we should use main memory for double buffering at the moment. He even said this might be faster than directly drawing on screen. We'll see. In any case, Axel says Dano "feels" faster than R5, so having double buffering it's probably better.
 
What issues with multi-user will the app_server deal with, and how will they be addressed?
 
Although the app_server is thought with multi-user support in mind, in R1 this won't be addressed. We haven't definitived the multi-user interface because Haiku R1 won't have support for that.
 
Are there plans to allow the app_server to be controlled via the network?
 
Controlled? No. In R2, there will be network support, this meaning: remote windows. If you want to control app_server from the network, I think the only solution is VNC. There must be some security if we're going to do that, and at the moment we haven't considered network support much, if at all. First we need a functional app_server - network support comes later.
 
Is localisation a factor in the design process at this point? Will it be outlined for at least R2?
 
Localization is something which is definitively planned for R2 because there is a major need for it to be done and done well. It would be nice to completely support OpenType, but when combined with the great many other things that we are planning for R2, it may be more than we can handle without having R2 take forever before releasing it.
 
What sort of latency issues will the app_server contend with?
 
I don't think app_server will suffer very much from that. The only 3 latency issues that I am aware of concern port communication, drawing on screen and the fact that drawing is done by the server, but none of them will be a problem.
 
Classes in libbe.so send a lot of small messages to app_server through kernel's port communication facility. Sending one message at a time is unpractical because introduces very high latency due to the context switch between app_server, client and kernel code in the CPU. As a result messages are cached in a 2K buffer (1K in case of R5) and sent at once.
 
A lot of these messages are drawing primitives (lines, circles, rectangles, bezier curves), and in an update request from server, all of them must be sent from client side to server side to be drawn on screen. This takes some time, and R1 must live with it. With the use of double buffering, this issue can disappear. We have decided that in R2 drawing would be made client side thus eliminating a lot of messages and context switches between applications, server and kernel code. I know you are wondering why shouldn't we implement this in R1? Well, we could, but need to do some serious changes and this will cost us time, time that we barely find for this project.
 
The last latency issue, would be that of drawing on screen. Without double buffering, drawing is done like this: the algorithm for drawing a circle is executed on the CPU, and each resulting point/pixel is written to a memory address. The problem is that, that pixel is written in video card's frame buffer, and for that to happen, those 3 bytes for a 24(32) bit color will go from CPU to PCI bus(33MHz!) into a part of video card's memory which is mapped on screen. This is a long and slow way, but it's the only way to draw on-screen. Also this is huge effort for just drawing one pixel.
 
By using double buffering, we have a contiguous place in main memory in which we can write *very* fast and then transfer as much as possible through PCI bus - Don't know the actual number but I bet it's many times more than 3 bytes. :-)
 

Stay tuned for more in part two, coming soon.