Rivo's blog

How to easily mix QWidgets and OpenGL

2008-07-24T21:28:00.001+03:00

Around a month ago there was a post at Trolltech Labs Blogs about embedding widgets in QGLWidget. I had been wanting to do something like that for KGLLib, so I downloaded the demo and took a look. It worked fine, but the code didn't exactly fit my purposes.
The demo did all the OpenGL rendering in the QGraphicsScene subclass. Usually it is done in QGLWidget subclass and I wanted a solution which would be as transparent as possible. Thus the rendering had to stay in GLWidget.
The second problem was the events. The event handling could have been done in QGraphicsView or QGraphicsScene subclass. But if I already have a GLWidget using event handlers, I'd prefer them to continue working as before. So some kind of smart event forwarding was needed to send the events either to the gl widget or to the graphicsview, depending on whether any of the QGV widgets had focus.

I have now solved both problems and the result is a class called WidgetProxy. It takes a GLWidget as an argument and creates a QGraphicsView object, using the GL widget as viewport. The OpenGL rendering is done in your GLWidget as usual and QWidgets can be drawn onto the OpenGL scene. It also tries to do the right thing concerning events: mouse events are sent to whatever is behind the cursor (QGV widget if there is one behind the cursor, otherwise to the GL widget). Keyboard events are sent to whatever has the focus.

It's really easy to use: if you have a toplevel QGLWidget and want to add widgets into it, all you have to do is first create the WidgetProxy object:

WidgetProxy* proxy = new WidgetProxy(myGLWidget);

and then add some widgets:

QWidget* embeddedWindow = proxy->createWindow("Window title"); embeddedWindow->layout()->addWidget(new QLabel("This is an embedded widget!", embeddedWindow));
embeddedWindow->move(10, 10); proxy->addWidget(embeddedWindow);

If the GLWidget is not toplevel but in a layout then the only difference is that you have to add the proxy, not the GLWidget, into the layout.

You can even show() or hide() the GLWidget and it works as before since the WidgetProxy intercepts those events, showing or hiding the QGraphicsView instead.
The aim is to make it possible to have widgets in OpenGL with pretty much a single line of code - often the user of the GL widget doesn't even need to know about it.

The code is now part of my KGLLib, along with an example ("widgets"). KGLLib's code can be found in KDE's SVN, in trunk/playground/libs/kgllib/.

New year, KWin and other stuff

2008-01-02T23:23:00.000+02:00

First let me wish you all happy new year :-)
2008 is certainly going to be an interesting year for KDE with the next major version finally being released and the focus shifting from refactoring to polishing and using the new APIs. I can't wait to see what people will come up with by the time KDE 4.1 or even 4.2 gets out.

KWin's compositing has seen many improvements in the last months, but we're still not completely sure if we want to enable it by default (even only for the selected cards and drivers). If we enable compositing and it unexpectedly fails for someone then there's the chance of him/her not getting a usable desktop at all and we're not sure if we want to risk with that...
Should we disable it for everyone by default (it's not difficult to enable anyway) and wait until we implement some safeguards for 4.1? Or should we enable it because it works for most people for whom it's enabled by default and end-users are less likely to adopt 4.0 anyway? What do you think?

I've also got a few more interesting things coming up, but I'll keep those for the next time ;-)

KWin improvements

2007-09-22T18:46:00.000+03:00

I first wanted to blog about KWin changes after returning from aKademy but then I never got to doing it. After that I've thought something like "once I'll complete this feature, I'll blog" a few times but then another interesting thing came up...
But finally, here's a summary of cool stuff that has happened in recent months:

One of the most interesting things is compositing settings autodetection. KWin now tries to detect your video driver and it's version and if it's good enough then compositing will be enabled by default. ATM it'll be enabled for NVidia drivers >= 96.39 and for Intel >= 20061017. If you know which settings work for another card/driver then please report it to kwin mailing list or post a comment here.

When you enable compositing yourself or change some of its settings, you'll get a confirmation dialog which will revert back to previous, hopefully working settings if you won't respond in 10 seconds (it's similar to the one you get when changing resolution. In fact there's plan to use exactly the same dialog). ATM it's a bit unreliable in that KWin sometimes crashes when reloading it's settings but hopefully it'll be fixed soon.

Speaking of KWin crashes, we're planning to make KWin restart itself in such cases (just like Plasma or KRunner) and eventually turn off compositing so that you'd always have a usable window manager, even when compositing has some problems.

Then there's the not-so-new-anymore compositing config module where you can turn on compositing and effects. Since a few days ago it also includes the entire list of effects so there's no separate "Window effects" config module for that anymore.

One of the biggest usability complaints - effect shortcuts aren't listed anywhere - is also starting to get solved. I added shortcuts to PresentWindows config module. I'm still not sure if all effects should have a config module just to show the shortcuts or if it would be better to just list the shortcut in effect's description (e.g. "Shows all desktops side by side when Ctrl+F8 is pressed"... or just "Shows all desktops side by side (Ctrl+F8)"). We've still got a little time to figure it out.

There are a few new effects as well. Invert and Sharpen effects were added during aKademy and Looking Glass - a fancier-looking magnifier - a little after it.

Old effects have received some polishing. PresentWindows and BoxSwitch both show window captions and icons. Shadows are nice and round (and unfortunately a bit slow). Some animations are faster, making KWin feel snappier.

I'm not posting any videos this time but if all goes well, you should see one in beta3's announcement.

Iconcache benchmarking results

2007-09-02T15:20:00.000+03:00

In the last three days I've been fixing some last bugs in KPixmapCache, benchmarking it and analyzing the results. Here they are.

It's going to be a long post, so the short story is: the cache reduces KDE startup time by about 1 second (~ 9%), depending on how many and which applications are autostarted. Startup time of individual applications is somewhat reduced as well, but the exact numbers depend on the application (more specifically, on how many icons they use).

I benchmarked KDE startup on two computers: my desktop and laptop.
Desktop is custom built with AMD Athlon 2800+, 1Gb memory and SATA hard drive.
Laptop is Dell Inspiron 6400, with Intel Core Duo T2350 with 2Gb of memory.
Operating system on both computers is Kubuntu Feisty, with all updates.
KDE was pretty much 4.0 beta2, I updated SVN at 29/08 about 1400 UTC.
I used a bit customized Bootchart and kpc-stats patch for benchmarking.

For numerical data I used two things: first, CPU time which is amount of time that system was not idle, gotten from /proc/uptime.
Second, startup time reported by kpc-stats which is time elapsed from when the first KPixmapCache object is created (by kded4 at the very beginning of the KDE session) until when the last icon is found or inserted to the cache (at which point all applications should be started). This can be thought of as a perceived startup time, it shows how long it takes until KDE is ready for use.
I tested with both default KDE startup (referred to as bare KDE) which starts only Plasma, Kicker, KWin, KTip (and background programs) as well as "full KDE" which also starts Konqueror, KBounce, KMPlot and Dolphin and is meant to simulate full KDE session where many programs are started and/or restored.
Every case was ran 3 or 4 times and average time was used. Disk caches were dropped before each run.

The numbers:
CPU time: Bare KDE on desktop computer: 9985 vs 8933 ms, win is 1052 ms or 11,8%. On laptop 6717 vs 6088 ms, win is 630 ms / 10,3%.
Full KDE: desktop - 20636 vs 19525 ms, win is 1111 ms / 5,7%. On laptop - 9722 vs 8968 ms, win: 755 ms / 8,4%.
Startup time: Bare KDE on desktop - 13810 vs 12572 ms, win is 1237 ms / 9,8%. On laptop - 9889 vs 9075 ms, win: 814 ms / 9,0%.
Full KDE: desktop - 24905 vs 23690 ms, win: 1215 ms / 5,1%. Laptop - 13138 vs 11965 ms, win: 1174 ms / 9,8%.

Some bootchart images:

Bare KDE startup on desktop, without (left) and with (right) iconcache.

Full KDE startup on laptop, without and with iconcache.

You can see from the numbers that the icon cache gives almost 10% improvement. Another interesting observation is that improvement in full KDE session isn't much bigger than in bare KDE. On desktop the improvement is pretty much the same, only in laptop is it a bit bigger with full session. Possible reason is that laptop's CPU is faster and thus I/O becomes bigger bottleneck, especially as it's HDD is also slower (5400 vs 7200 rpm).
Most of the 1-second improvement probably comes from the fact that icon theme initialization, which scans all icon dirs, can be skipped when icon cache is present because needed info is already stored in the iconcache header.
You can visually see the improvement when flipping between bootchart image pairs. On with-iconcache images, the later part of the graph has shifted about 1-1.5 seconds forward. You can also see there that the 1-second improvement comes from kded process which is where the expensive icontheme initialization takes place.

I didn't benchmark the applications again since I have already done so earlier (and the numbers shouldn't be really different) and because it was more painful to do than benchmarking full KDE.
Only exception was Dolphin which was the first app I tried to benchmark (after that one I didn't bother with the rest) and which showed a 400ms (11.4 vs 11.0 sec) improvement in cpu time and 1.5 sec (12.6 vs 11.1 sec) improvement in startup time. This fits with my earlier benchmarks quite well. Also note that the earlier benchmarks were all done on the laptop while this one was done on desktop, that's why the absolute times are so different.

Last but not least, keep in mind that absolute performance improvements aren't the only advantage the icon cache brings. It also makes some things possible which would have been way too slow without it. Also there's the generic pixmap cache which is already being used in quite a few games to speed up rendering of game elements and background from SVGs.

And finally, since this is quite likely my last GSoC-related post, I'd like to thank my mentors and the whole KDE community for helping and supporting me as well as Google for organizing the SoC and supporting open-source development.
Keep up the great work everyone! :-)

KDE OpenGL library?

2007-08-28T20:47:00.000+03:00

Lately I've gotten the feeling that OpenGL is really going mainstream, including in KDE. We already have quite a few apps that are using it and it looks like more are coming.
However ATM many of those apps are reinventing the wheel by writing same generic code such as a texture class over and over again.

So I got the idea of creating some kind of KDE OpenGL library. It would have Qt-style API that KDE developers would be familiar with and would provide some common building blocks that would ease development of OpenGL apps. Right now I'm thinking texture and shader classes, maybe a camera class, some common functions, vector library (Eigen should be great for that) and perhaps an extension library (GLEW could be used). I don't want too many things though, it should still stay lightweight instead of becoming yet another fully featured 3d engine.
And it should be extensible. If your app needs e.g. cubemap textures, you should be able to write a CubemapTexture class that inherits from Texture class and provides necessary functionality. Such extensions could even be put into a common place so that other apps could copy them into their own source tree and use them without bloating the library.
The library probably needn't depend on KDE itself, just on Qt. This might make it interesting for pure Qt apps as well.

What do you think of that idea? Would you use such a library? Or know someone/something that might? Add your comments here.

Iconcache is Done :-)

2007-08-22T19:15:00.000+03:00

The coding phase of the Summer of Code is now over (for two days already).
Within the last days I managed to add mmap-implementation which instead of opening/reading/closing cache files all the time maps them into shared memory and then just uses that memory. It seems to increase performance (of reading icons from the cache) by about 30%. More than I anticipated.

In the end I managed to get in all the features and ideas that I had, so the work on the icon/pixmap cache can be considered complete now. There might of course be some smaller performance tweaking and bugfixing and apidocs additions and so on, but I don't expect to do any bigger changes.
It also means that if you see a bug concerning icon loading or pixmap cache (I hope you won't ;-) then report it. Either contact me directly or add a comment here or whatever.

I still haven't gotten to doing the final benchmarking... maybe at the end of this week or in the next one...

Iconcache status

2007-08-17T19:15:00.000+03:00

Summer of Code is ending (the official deadline for writing code is 20th August) and so my work on the icon cache is also coming to an end.

Yesterday I committed the last crucial piece of code. The cache now periodically checks for icon theme updates, so as soon as you install some new icons, they should be used and the obsolete cache be discarded.
This means that the cache is now fd.o icontheme spec-compliant and all the necessary features should be implemented :-)

Some smaller things remain to be done, such as further performance improvements and final benchmarking. I hope to complete the code part in the coming days and most of benchmarking will probably be done after the 20th.

Speaking of benchmarks, I did some a few days ago. As you have probably heard already, perhaps the most extreme case is kfind which starts up in about 4 secs without the cache and in a bit less than 1 sec (of which just 300ms is icon loading) with the cache. That's with hot caches (i.e. operating system has cached some of the data already). With cold caches it's 12secs vs 2.5secs.
Dolphin uses quite a few icons as well. With cold caches it takes 3.9 secs with iconcache and 5.2 secs without it to start. With hot caches it's 1.2 vs 1.5 secs.

I also noticed about one second improvement (12 vs 13 secs) in full KDE session startup time (with Dolphin, Konqueror, Konsole and KBounce autostarted). I have to admit it's a bit less than I had hoped for, but KDE's startup time will probably be improved prior to 4.0 anyway. Anyway I will make further benchmarks to find out more accurate numbers.

The times are measured from when KPixmapCache contructor is called (which should be at most 100ms after the program is started) until the last find() call (after which the application should be ready to be used).

Icon/pixmap cache now in kdelibs

2007-07-20T14:05:00.000+03:00

As the title says, I've finally merged my Summer of Code project - icon and pixmap cache - into kdelibs.

Buildsystem changes are not done yet, I'll do them in the next days. Until then, you might see old icons after new ones are installed. If you really need the new ones, do touch -m $KDEDIR/share/icons/hicolor/. Then the cache will notice the new icons.

The pixmap cache is meant to make disk caching of e.g. pixmaps rendered from SVGs very easy for app developers. It's API is similar to that of the QPixmapCache and I'm planning to create a TechBase tutorial soon to make it's adoption even easier.

My first plasmoid

2007-07-18T15:34:00.000+03:00

Now that Zack has made it possible to create 3D plasmoids I had to try writing one myself, too.

It renders a virtual Earth model on your desktop, with subtle rotate animation and a day/night cycle, using NASA's Blue Marble imagery. And it has a rather crappy atmosphere as well.
It requires a shader-capable videocard to work, so minimum requirements are GeForce FX or Radeon 9500 although you'll want to use a bit better card than those for any smoothness.

It doesn't have any useful functionality, but if you just want to waste your processing power, then it does a pretty good job ;-)

The code can be found in KDE's SVN in playground/base/plasma/applets/bluemarble/.

aKademy impressions

2007-07-11T16:41:00.000+03:00

I'm one of the many KDE people who spent the last week in Glasgow, at aKademy 2007. It was a really great event and the first chance for me to meet many KDE people in real life.

The arrival went quite smoothly. I arrived late Sunday, a day after the incident at the Glasgow International. Luckily there weren't any problems there, although one could see higher security measures such as concrete blocks before the main entrance and a group of police with SMGs.

The problems started once I reached my hostel. I was supposed to be in a room with three other SoC students. But as it turned out, there were four others instead of three so my bed was already taken. After some searching they put me in another room. In the morning I was told I'd stay in that room until my departure, but to my surprise all my things had been removed when I went back in the evening. After talking to the staff again, they gave me yet another room. And after staying in two different rooms for two nights, they finally told me I should go and talk to the organizing team as they really don't have a place for me. So I went and talked to Kenny Duffus who put me into the university accommodation which was much more convenient and more importantly absolutely problem free. Big thank you to Kenny Duffus and the rest of the aKademy team for sorting that out (not to mention organizing this great event) :-)

Other than the hostel issue, everything was great. I met many KDE people, including my mentors Seli and aseigo whom I brought some chocolate for their good work (and almost made aseigo cry in the process ;-)). We also had a nice barbeque out of the city on Thursday although the end of it was somewhat ruined by the rain (yeah, it rained quite a bit in Scotland).

Tons of work also got done. There was a heap of additions to KWin which probably deserve their own blog post. Also, there were some very important additions to my icon cache. It got split into two classes: KIconCache, which is the KDE-wide icon cache, and KPixmapCache which provides application-specific cache functionality. This way e.g. applications that use SVGs so that they can cache the generated pixmaps without having to regenerate them every startup. The code is available from KDE SVN, under /branches/soc-iconcache/. It contains kdeui replacement (which I'm trying to keep mostly up-to-date with the trunk), a demo app showing how to use the app-specific caches as well as an old visualization app which was meant to list all entires in the icon cache but doesn't work anymore due to file format changes and me being too lazy to update it...
I've still got some hope to get this into 4.0 as there certainly would be apps in kdeedu and kdegames that would make use of it. And probably Plasma as well. We should know for sure in a week or two.

KWin performance and shadows

2007-06-15T20:06:00.000+03:00

After publishing my last KWin video, the biggest critique was that KWin is slow. Most of that could be attributed to the video recording which naturally makes things slower, but e.g. Beryl still felt smoother than KWin. I decided to investigate it and one thing I found out was that TFP (texture from pixmap) mode was actually slower than SHM (shared memory) mode. A lot slower even, especially when just part of a window changed. I still haven't figured out why exactly it happens (I'm using NVidia drivers, don't know if that's related) or if it's same with Compiz/Beryl, but if you want to switch to SHM mode, this command does that:

kwriteconfig --file kwinrc --group Translucency --key GLMode SHM

After executing that you can restart kwin by executing kwin --replace
Additionally, turning off vsync might also make it feel a bit better, but be warned that you might experience some tearing in this case:

kwriteconfig --file kwinrc --group Translucency --key GLVSync false

About KWin development, it has gotten some compositing fixes & improvements lately, and I have a new eyecandy screenshot to show as well. I implemented soft shadows for windows. They still suck a bit (especially at the corners), but less than before and it should be possible to improve the corners with some more work as well.

KWin effects config & another video

2007-05-29T19:55:00.000+03:00

During the last days I've been working on making KWin's effects configurable from a KConfig module. Until now, if you wanted to enable/disable an effect, your only possibility was using DBus. DBus support is still there of course, but now you can alternatively use KPluginSelector widget (which got a nice makeover thanks to Rafael Fernandez Lopez aka ereslibre) which shows up among other KWin config modules when you RMB on window title and choose "Configure Window Behaviour".
Internally, KWin effects are now services, so we use ksycoca to get a list of them as well as find out in which library a given effect is. This made the code tiny bit simpler and might also result in some performance improvement.

Additionally, effects can now have their own config modules as well, so you can fine-tune them to your personal preference. ATM only two effects (shadow and presentwindows) are configurable, but more will certainly follow.

I wanted to make a video of config possibilites, but it evolved into a much longer video which briefly shows you how to enable compositing and how to choose and configure effects. It also shows some of the (IMHO) more important effects. The 6-minute video can be found at YouTube.
Update: there's also 16mb .avi with slightly better quality, but it's server could be slower than YouTube.

Finally, it looks like I've been added to Planet KDE :-)
If you're interested in more KWin stuff, you might want to check out my previous post as well.

KWin videos, blur effect

2007-05-03T21:11:00.000+03:00

Almost a week ago I added blur effect to KWin. It's purpose is to blur background of translucent windows to make text in such windows more readable. With standard translucency, if there's a window containing text below a translucent window, then the text in the translucent window is hardly readable. The effect blurs out fine details such as text, resulting in much better and usable transparency. While the background windows are blurred, they're still visible enough to see movement or changes, making transparency useful for e.g. monitoring activity of Konsole windows.

I've made two videos as well. First one (YouTube link, direct link) shows just a silly demo effect that applies some waves to your desktop. It's not physical simulation of liquid, though that would now be possible as well in case anyone's interested ;-)

The second one (YouTube, direct) shows the blur effect itself. Also note that in conjunction with the fade effect, which makes windows smoothly fade in/out when they're created/destroyed, it blurs out background of new windows when they fade in. It's subtle, but you can see it with menus in the video.

Update: added YouTube links for both videos.

Introduction

2007-05-03T17:13:00.000+03:00

Hello everyone.

Short introduction: I'm an Estonian student, soon finishing my first year in university. I've been involved in open-source development for several years, working on the Boson game in the past though unfortunately it's development has halted for now.

Since the beginning of this year I've been involved in KWin development, creating various compositing effects as well as separating effects interface into a library to support 3rd-party effects. Stay tuned for more KWin-related stuff soon.

Last but not least, I was accepted into Google's Summer of Code program and will be working on an icon cache, mentored by aseigo. The purpose of it is to make application startup faster by putting icons into cache which eliminates the need to search for them on the disk (there are many directories where the icons might be and searching through them takes time). Also it will act as SVG cache so that SVG icons can be used without having to convert them into raster format every time.

This blog will contain news about KWin, my GSoC project and anything else KDE-related that I might be working on in the future.