gunnar
Graphics View
Painting
Graphics Dojo
Graphics
Posted by gunnar
 in Graphics View, Painting, Graphics Dojo, Graphics
 on Tuesday, March 03, 2009 @ 12:42

For Qt 4.5, the development team has worked hard with performance. There have been a few blogs on the topic already, but I was asked to give a small chat about it from a slightly higher-level perspective, now that the release is finally out.

It is extremely annoying for a user to sit and wait for a file dialog – so Alexis did something about it! Looking at the, admittedly extreme, case of showing 10000 sub-directories, the time for local folders has changed from 21 seconds to 360 milliseconds. The speed up in this case came from three major areas. The internal data model was rewritten to scale better, a cache of filesystem icons was introduced to avoid fetching these from the system for every individual file or directory. Finally, he sat down with the itemview guys and tweaked the treeview and listview classes to perform a bit better, so there should be some candy in it for itemview users in general.

Accessing the same folder over the locally shared network, the improvement is smaller in percentage, but reduces the waiting time from “hey my application has crashed” to “I really need to do something about my directory structure“. Its down from 77 seconds, to 17 seconds. Again, much because of the datastructure rewrite.

filedialog

You might recognize the chip demo in the image below. Forty thousand chips, each with an individual text, together forming a picture of parts of the Qt crew. Back when we launched Qt 4 we thought that was pretty cool. It still it, but from Qt 4.5 is will be faster. The improvements range from around 30% on Windows for most zoomed out operations to 5-100 times better performance on Linux with the raster paint engine.

chipdemo

Prior to calling QGraphicsItem::paint() there is a little bit of work involved in figuring out exposed areas, the items StyleOption, intersecting shapes, clips etc. The graphicsview guys, Andreas, Alexis, Ariya and Bjørn Erik, have spent quite a bit of time in minimizing the effort spent here.

Also, when zoomed out, the chips are drawn using a painter.fillRect(rect, color) which in 4.4 allocated a brush. Both on the opengl paint engine and the software paint engine this path is now, malloc free, which again brings down its cost quite a bit. As for software outperforming X11, the use-case fits very well to the software engine. Lots of small transformed primitives (small being important) with different colors, transformations etc. Specially state-handling is a lot more complicated in the X11 paint engine.

However, the biggest improvements come with nested items. Examples of this is when moving groups of items by moving their parents, source here. When moving a top-level item containing fifty children that, in turn, holds ten children each, in a scene with one hundred top-level items (all in all, moving 551 items in a scene of 55100 items) the speed improvements range from 20-64 times – check out the bars below for the bigger picture.

graphicschildren

Again, QGraphicsView has gotten a lot simpler in the “stuff” it does between paint(), like how often it goes up and the parent chain to figure out current transformation etc. Also, the example relies on clipping which was sped up quite a bit in 4.5 for raster and the opengl engines, particularly where save/restore is involved.

Learn more about the performance improvements introduced with Qt 4.5 by reading a new whitepaper prepared for the release. (Sorry, but it seems registration is necessary to access it ;) )

10 Responses to “Performance and Qt 4.5”

» Posted by Thomi
 on Tuesday, March 03, 2009 @ 13:35

Am I missing something here? It seems to me that in both graphs there is one bar missing - either that or it’s too small to see.

I.e.- Speed to open a local folder under 4.5, and the windows QGraphicsView.

» Posted by Rolf
 on Tuesday, March 03, 2009 @ 13:40

@Thomi: It’s 360ms. Too small to see in this scale.

» Posted by Dawit A
 on Tuesday, March 03, 2009 @ 17:54

The performance improvement for accessing shared folders is excellent news! But I have one question… Does this improvement also apply to QDirModel or is it limited to QFileDialog ?

» Posted by Joe
 on Tuesday, March 03, 2009 @ 23:44

Why is Windows still so much faster than Linux? Is that a problem of X, the drivers, or something else?

» Posted by Andrew Ash
 on Wednesday, March 04, 2009 @ 03:49

Excellent work with the performance increases! I’m wondering the same thing as Joe: what is the cause for the huge discrepancy between the Windows and Linux versions of Qt? Maybe some investigation into the differences would lead to even more speed improvements.

» Posted by Alexis Menard
 on Wednesday, March 04, 2009 @ 09:39

@Dawit A : Those improvements apply on both QFileDialog and QFileSystemModel. QDirModel is like it was before. Btw you should use QFileSystemModel instead of QDirModel.

» Reply from gunnar
 on Wednesday, March 04, 2009 @ 12:18
gunnar

@Andrew & Joe: The difference between linux and windows can be contributed to a number of factors. The only place in the code where the software engine has special code for windows is in relation to font drawing where the windows code is somewhat more optimized, so that shouldn’t be too influential. Depending on the hardware the blit to screen can take more or less time on the device. There is also a point in that MSVC tends to produce more optimal code than GCC.

» Posted by Christoph Bartoschek
 on Thursday, March 05, 2009 @ 10:03

When will the mentioned Performance Whitepaper be available? I registered at least twice, but got no mail yet.

» Reply from gunnar
 on Friday, March 06, 2009 @ 07:03
gunnar

@Christoph: The whitepaper is already available. I registered and got it in my inbox a few seconds later. Maybe it gets caught by some spam filter on your side or that your mailserver blocks mails with .pdf attachments?

» Posted by Ivan Korotkov
 on Sunday, March 08, 2009 @ 16:05

Rendering speed improvement looks really great in 4.5, fine job done! However, I couldn’t make font anti-aliasing work correctly when using OpenGL graphicssystem: looks like most glyphs are rendered with different anti-aliasing options than those from fonts.conf (which all other applications and ‘raster’ graphicssystem uses). Does opengl graphicssystem use FreeType at all when rasterizing, or it uses it’s own font engine? Are there any settings I can tweak to improve anti-aliasing?



© 2008 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners.