Hi Petr, On 08/01/2012 11:07 PM, Petr Koupý wrote: > 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
I will borrow two phrases from old computer games to express my current level of satisfaction: "Impressive!" and "Very good job!". > If you want to try it for yourself, checkout lp:~petr-koupy/helenos/gui > branch. In fact, I've been spying on your branch for some time and was very excited about where it is taking HelenOS. Btw, I also made a small demo of your graphics stack (with due attributions) to the MINIX 3 group. Hope you don't mind :-) > 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. I bet the whole native thing is also relatively small (in LOC), isn't it? > 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. Thanks for the detailed description, I really enjoyed it, even though I am definitely not a graphics guy. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
