Hi, after several months of development, I would like to announce that HelenOS graphics stack is finished, at least for the purposes of my diploma thesis. To be more specific, while the stack is complete on all levels in its breadth, implementation depth is definitely open-ended problem for months and years to come.
Before diving into more details, I suggest you to watch demonstration screencast at http://www.youtube.com/watch?v=ZjqYRv2xOSw If you want to try it for yourself, checkout lp:~petr-koupy/helenos/gui branch. In build configuration, select "Prefer pixel-based compositor" option and setup at least 1024x768 framebuffer. Also, setup your virtual machine so it has at least 128MB of RAM. Here is the list of controls: - move window (Alt+WSAD, mouse dragging with left button pressed in window header) - resize window (Alt+TGBN, mouse dragging with left button pressed in window border) - select window (Atl+Tab, left mouse button anywhere in the window) - close window (Alt+X, left mouse button onto "x" symbol in top-right window corner) - scale window (Alt+RF, mouse dragging with right button pressed in window border) - rotate window (Alt+QE) - window opacity (Alt+CV) - move viewport (Alt+IKJL) - select viewport (Alt+OP) - kernel console (Alt+M) In the rest of the email, I will describe some technical details and limits of the implementation. Keep in mind however, that this is just a quick introduction so you can make sense of it and possibly merge it to the mainline. Proper design documentation will be part of my diploma thesis, which is not written yet (and won't be available for a few next months at least). Before starting the description, I would also like to stress that although I did architectural and design investigation of various third-party software, I did not port any of them into HelenOS graphics stack. The main reason for such decision was my GSoC experience from last summer - i.e. that porting of third party software could be quite messy and time demanding. It would be simply too risky and not very relevant for the purposes of my thesis. Firstly, I will describe bottom (or first tier) of the stack. The old fb server was replaced by devman and libgraph, which is the library containing common interface and functionality for graphic drivers. Although currently untestable, libgraph should be capable of handling multiple viewports, each of which belongs to some graphic adapter and represents one of its physical or virtual outputs. Original framebuffer and serial drivers are still the only available graphic drivers. They were only slightly adjusted to work with the new interface provided by libgraph. In the second tier, there is either compositor server or console server, depending on which was selected in the build configuration. Compositor server is available on the same platforms where there is a framebuffer support (apart from arm32 and ppc32, where additional symbols have to be added into softfloat library). New console server is available everywhere, as was the original console server. While the new console server is conceptually based on the original console server, it was cleaned-up to be purely character-based and partly reimplemented to support resizing. As for resizing, note that the application running in the console must also support dynamic change of dimensions, otherwise its layout will break when the size is changed. I improved bdsh implementation so it is aware of resizing, but there is no way I could add such support into all HelenOS applications in the given time frame reserved for my thesis (also such endeavour would be out of the thesis topic). Speaking of limits, I also decided not to implement console history/scrolling to save some time (however I kept it in mind when redesigning and reimplementing the console). Another pragmatic decision regarding console was to keep support just for a single viewport, which means that each terminal window must spawn new console server instance. While it would be nice to have just one instance of console for the whole system, it is not critical for my topic and I strongly believe I would not deliver rest of the features below (which are actually critical) in time if I had decided otherwise. Now the compositor server. In short, it manages infinite (for practical purposes) desktop onto which several viewports and surfaces are placed. What can be done with these entities was already shown in the screencast. To support such features, there are two libraries on which the compositor is dependent - libsoftrend and libdraw. While libsoftrend contains mainly mathematical operations (pixel conversions, alpha-compositing, matrix transformations, filtering) that could be accelerated in future through libgraph and graphics driver, libdraw contains the rest of the drawing features (surface, file codecs, font rendering, drawing context, drawing functions). The functionality of both libraries was implemented on-demand, so there are just empty function bodies for more advanced features (e.g. bilinear filtering, line drawing, curve drawing). Also the rotation matrix currently supports only 90-degree rotation, since there are no trigonometric functions in libc. Another thing you could notice in the screencast is that the surface transformations does not gradually follow the mouse pointer while it is moving - while such animations are implemented and can be experimentally enabled, it is hopelessly slow without hardware blitter, therefore disabled by default. Finally, the third tier of the stack contains basic widget toolkit implemented in the libgui. It contains resizable windows (including decorations), event loop, scene graph, signal-slot mechanism and object hierarchy of widgets. Currently, there are only 4 widgets - grid, label, button and terminal. Grid serves as a basic adaptable widget layout to enable creation of simple GUI applications. While the label and button widget do not require any explanation, the terminal is more complicated - it is basically an emulator of the first tier linked to the libgraph, so the spawned console servers can render their output into emulated viewports. As you could see in the screencast, there are currently only three GUI applications available - vterm, vdemo and vlaunch. The launcher is started inside HelenOS init application, so other GUI applications could be started later by the user. And that's basically it. I personally hope, that the gui branch will be ultimately merged into mainline, so the community could gradually improve depth and mentioned limits of the current implementation. If, for whatever reason, you won't like it, it could be at least cherry-picked as some other HelenOS-related theses. As of writing this, the gui branch is fully in sync with the mainline and I am able to keep it that way for the next couple of months while writing the text of the thesis. If you eventually decide to merge it, I suggest it should be done sometimes after the upcoming major release of HelenOS, because the graphic stack is not extensively tested, but before Martin's ifaces branch which is partially changing the communication code across the whole system. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
