GUI Changes / Desktop composing

Submitted by Robert Szeleney on Mon, 2006-04-03 14:42.

Right after Build 5550 was released work on the new GUI rendering began.


(click screenshot for more information...)

From the very first SkyOS version up until Build 5550 the GUI redraw handling was implemented in following way:

  • Whenever an area of a window got exposed, or the window content changed, the redraw routine from the widget was called
  • The widget private GraphicContext was used to draw the widget itself. The drawing was done directly onto the screen. GIWM clipped every drawing operations to the visible rectangles of the window

This method had some drastic disadvantages:

  • High CPU usage. The redraw which could happen a few hundred times per second required a lot of CPU power
  • Flickering. Redrawing the widget "flickered" if the widget itself didn't implement double buffering
  • Speed. The frequent data transfers between CPU and VRAM over the slow PCI bus slowed down the entire GUI
  • ...

The new rendering engine
The main difference is that the window content is now buffered. The drawing operations don't draw on the screen anymore, but they draw into a application window private layer. The only time a widget has to redraw itself now, is:

  • When the widget gets created
  • When the size changes
  • When the actual displayed content must be changed

The part which is responsible for bringing the actual window content onto the screen is the GIWM Composer. This plugin based Composer takes the offscreen layers from every window and composed the actual desktop layout.
Before sending the window content to the screen the Composer may perform various operations on the layer surface.
These operations (which are implemented in loadable plugins) may perform things like Alpha blending, Color conversion, Scaling, etc. (On a side note, there is also an interesting "debug" plugin which slowes down the redraws and draws a red rectangle about regions which are going to be updated.)

To conclude, this change has following advantages:

  • Speed. Because not utilizing the PCI/AGP bus that much, the GUI gained a dramatical speed increase.
  • Composing. A window content can now be blitted with various effects. (Alpha, translucent, colorize, scale, ....)
  • CPU Usage. Much lower CPU Usage because of lesser widget redraw operations
  • Layers. Applications can access the content from other windows. For instance, the Application Manager (ALT+TAB) displays a preview of the applications
  • etc...

No source changes in your applications are required for all these changes.

Proof-of-concept implementation of the window transparency and window shapes (window shadows disabled):

Proof-of-concept implementation of the new application manager showing live previews of opened applications:



tflQZd

svcqxZqK tflQZd

ixchmjC

PsyjFmzY ixchmjC

Live Sex livestock Adherence

Live Sex livestock Adherence

I think

i enjoyed reading the article, and we at the SkyOS forums had been waiting for it for quite some time now...glad to see it went live. I was surprised that Robert hadn't tried other OSen as well, but i guess it's better that way, as he can create features on his own, without worrying about what others are doing. I successfully ran SkyOS in QEMU (can't install to HD for some reason) and I was very happy with the speed and performance, even though I was running an emulated OS. Very nice...I could only imagine the speed when it runs native. I think once the next two betas come out (networking and usb), then SkyOS will really be something I (and others) can really start playing with. As Thom mentioned, networking is a huge part of an OS nowadays, and it will help bring SkyOS to the forefront. I don't doubt Robert or his OS' capabilities and potential for the future.

Release

When new alpha build started?

don't spam please - Peter

Glad to see these changes

Glad to see these changes getting done. Can't wait to test it out. Keep up the awesome work!

does it ...

I know that MacOS X and the upcoming Vista hav the ability to render aplication windows to textures and then let the graphics card in 3D mode handle drawing etc. So the graphics card accelerates moving windows around, clipping etc. I beleive it is accomplished by rendering a quad for each window with the Z buffer disabled based on the order you want the windows to be stacked. Icons can also be individual quads, etc.

Are there any plans for SkyOS to have this sort of capability? Would be nice for people who have supported gfx cards.

WOHOO!

Can you please release a new alpha build of this, like yesterday? lol

oh yes!

come on, please say that movie is playing full speed while being alpha blended and moving the window, could it be the SkyOS UI is finally going to be responsive?

backside buffers ...

A backside buffer for each window to draw on?

What's the memory usage? I just wonder, remembering a discussion where I've been told that backside buffer per window would cost too much memory.

stay safe :-)

why not a Xgl implementation???

why not a xgl implementation and use the compiz plugins???

really cool

(a little late) This is a really cool feature. It works suprisingly well! I do have some ideas though, which I'll post in the forum.

Nice job

I can't wait to see SSes or videos of this in action!

Released. :)

Released. :)

Darkness told me that for

Darkness told me that for him a video plays at full speed if the mediacenter itself is transparent and below another transparent window. (this was with SkyOS running in VMWare)

Icons and buttons

Maybe it's because of application backwards compatibility that individual icons, buttons, comboboxes etc aren't drawn by OpenGL API but as pixelmap. Somehow I find it cludge to just render this plain old pixmap as texture.

Does QT already have some support to do the actual drawing of button etc. through OpenGL?

http://doc.trolltech.com/4.1/qt4-arthur.html
"How Painting is Done in Qt 4"

If you have a powerful

If you have a powerful graphic card, memory usage for backbuffer drawing is equal to zero. (The window content will be placed in the graphic VRAM).
Even without a supported graphic card, memory usage isn't that bad at all. You propably need around 10MB for a typical usage.

Oh dear lord

Good god man. I shouldn't even dignify that with a response.

I know that MacOS X and the

I know that MacOS X and the upcoming Vista hav the ability to render aplication windows to textures and then let the graphics card in 3D mode handle drawing etc. So the graphics card accelerates moving windows around, clipping etc. I beleive it is accomplished by rendering a quad for each window with the Z buffer disabled based on the order you want the windows to be stacked. Icons can also be individual quads, etc.

Are there any plans for SkyOS to have this sort of capability? Would be nice for people who have supported gfx cards.
_____
rolex

I still don't believe that

I still don't believe that project like SkyOS can succeed without releasing sources under some kind of free license. It is a shame that they can't see that neither Zeta or SkyOS, even though they are both interesting projects, won't change anything on OS scene.

software downloads

It looks as if you have put

It looks as if you have put quite some thoughts on it.

In my own os project I have developed gui drawing stuff by using a global backside buffer for all windows, thus saving memory - but to what cost: each and every drawing operation has to be clipped, and that's quite tedious and power consuming. Or maybe I'm doing it the wrong way.

It seems easier to clip a region and then memcpy the blocks to draw from the respective backside buffer to the screen than to clip a region and test each and every drawing operation against the clips. yeah. That'd ease client side drawing immensely.

Thinking about it ... I reckon I should give it a try. It would render drawing translucent windows into a flick of cpu work.

Thanks for input :-)