Tag Archives: 4.5

Netbook and performance

Software

Probably I should had written this little notice uhm, a quite while :), anyways, it’s quite technical but here there are a little hint on how to make the Netbook shell a garzillion times faster, if you’re hit by an unfortunate series of circumstances that makes it run sloooowly 🙂

Why on some netbooks it runs slow

As shown here, The Plasma Netbook shell can be quite fast on a standard netbook, however many are experiencing it going rather slow. Why?

Qt can use different graphics backends to render the graphics, now on X11 systems the default is the one that is called surprisingly enough, X11, that relies heavily on XLib and XRender. Now, this sounds allgreat, but two things tends to happen.

If the Xrender acceleration of the video drivers is pretty poor, things tend to slow down.

Second, if QPainter hits some code patch that aren’t directly implemented via the X11 graphics system it will have to fall back to another paint system: raster, that is totally software based, so pixmap-to-image conversion (and memory copy) is involved (and is necessary, to not actually lose features depending on what graphics system you’re on), and things slow down.

Now, with Intel drivers things seem to not go soo well, especially for items clipping: that’s unfortunately what’s used more heavily in Plasma Netbook 🙂 the newspaper and the search and launch result works as follows: a smaller QGraphicsWidget contains a bigger one, that contains the actual contents that could be the plasmoids of the newspaper for instance. the outer widget has a particular flag that enables clipping, so what overflows from the parent widget won’t be actually drawn.

with Intel drivers and the X11 graphics system this seems to be pretty fast until the parent widget is of a certain size, then performance degrades significantly pretty quickly.

The actual how to

So the alternative is to use the raster graphicssystem from the start, that is really fast (especially if one think about that is completely software based rendering) there are basically 3 ways to do it:

the application can be invoked with the graphicssystem commanline switch, so:

plasma-netbook -graphicssystem raster

But this has to be done every time, or Qt can be configured at build time to use this as default (some distributions such as Gentoo or MeeGo actually do this) but will have the effect on every Qt application.

So I’ve added a config file option in Plasma Netbook to use it as default even if Qt has X11 as default: with Plasma Netbook not running, edit the file

~/.kde/share/config/plasma-netbookrc (in some distributions could be ~/.kde4 instead)

And add the following line:

GraphicsSystem=raster

That’s it 🙂

Here is a video that compares before and after on the usual EeePC 1005ha, with a bright note: the difference isn’t anymore so noticeable like it was used to some months ago, even tough it’s still makes the difference.

OGG version

Why isn’t the default?

Two reasons: it’s still quite unstable sometimes, overall with X11 Plasma (and other Kde apps as well) seems to (still) be more stable.

But most importat, as said it’s purely software based, so it could be not so gentle on the CPU (so with the battery life). I mean, it’s impressive how much it’s efficient, but will never belike a working gpu based solution. So if you aren’t running on the problem described before, it’s probably better you keep it as is.

So there is hope for the future?

Absolutely! a still experimental new graphics system is in the works, using this time OpenGL. The whole application (any Qt one actually) can be run completely with OpenGl drawing with the -graphicssystem opengl, or just a QGraphicsView can use it (by using a QGLWidget as viewport). That’s exactly what happens if you start Plasma Netbook with

plasma-netbook --opengl

This works in the new born Plasma Mobile too by the way. and is a great hope especially in those two sheels, since GPUs of small devices are designed to be not soo fast, but to be very low power, a bit less than the cpu, actually.

Right now, as in KDE SC 4.5 and Qt 4.6/4.7 is still not for everyday use, is still not so stable and there are some graphical glithces (this actually varies from a graphics driver/video card model like crazy) but what is encouraging is that since this feature was introduced (Qt 4.4) it came a very long way, it’s really sooo better than when it was originally out.

The future of notifications

Software

Warning: this post belongs to the category of the evil teaser ones, that announces features for the release after the next near one 😀

KDE SC 4.4 has some improvements to the notification system, as I shown there, but still some problems remains:

The popup can still be very big, covering a big part of the screen, stealing input area or just being too big for smaller screens.

Also, being notifications and jobs shown in the same window, it automatically shows again and again the same information, being the individual job progress when a new notification arrives r vice versa.

So, things are changed a bit in trunk (so what will be 4.5) let’s look at a video worth more than 1024 words:

OGG version

This is of course still subject to change a lot before 4.5 release, but it’s on the right track.

When a new notification arrives, it is shown by a popup on its own, without jobs progress. This popup only shows a notification at a time partially covering all the others (maximum 4 total) in order to save space. to see a covered notification is enough to pass the mouse over its title.

The big popup accessible by clicking the “i” button is still quite big indeed but is only shown when the user asks explicitly for it. it shows the usual individual job progress and the old notifications browser introduced in 4.4, where is possible to filter by application. Is a convenient place to search what happened to the PC when you were away for instance.

Similarly, when there are jobs running, the big popup is not shown, but only a really tiny global progress bar, that can even covered by the windows, so won’t be blocking any mouse input to precious areas of the screen.

Another nice thing is that if you compare it with widgets like The microblog plasmoid or the opendesktop ones you see that a very common design pattern is emerging for similar things, making the experience pretty consistent.

notifications and microblog