Hi Petr. 2012/8/1 Petr Koupý <[email protected]>: > 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. Amazing. And finally it is possible to play Tetris upside-down :-). Not talking about other advantages as seeing output of more than one terminal. Really good job.
I have one question and one small bug report. Where is klog? I haven't found it in any console/terminal. When playing tetris 90 deg rotated, a single-pixel line remains drawn in previous position of the falling block. Screenshot is attached. But I am not sure that this is not something related rather to Qemu than to your server. Thanks and one more time, good job. - Vojta > > 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
<<attachment: tetris_cube_trace.png>>
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
