Richard Moe Gustavsen

Alien widgets on Mac

Published Wednesday February 23rd, 2011
24 Comments on Alien widgets on Mac
Posted in C++, macOS, Performance

Up till now, every widget in Qt/Mac has been backed by its own NSView. This means that Qt keeps a parent-child hierarchy of views in Cocoa that more or less mirrors the hierarchy of widgets found in your application. Each view receives native events that gets forwarded to the corresponding widget. We then need to do some extra processing and redirection to implement Qt’s own logic for doing implicit and explicit mouse grabs, popups, etc, before the events eventually gets converted into QEvents and sent down to the application in a platform independent way.

Apple states that you should be careful not to overuse NSViews (ref). Instead, you should try to keep the count below one hundred for optimization reasons. This means that if you create Qt applications that make heavy use of widgets, your application would easily hit this limit. The result can be bad, as the first movie below shows. The application recorded creates a silly count of 2000 widgets that each highlights a button as the mouse hovers over it. And as you can see, the example just doesn’t scale up, resulting in a huge lag.

Since we know that some of our customers tend to use a lot of widgets to build fancy UI-s, this limit can sometimes be critical. Luckily, Qt has a solution to this problem called Alien widgets (ref). Alien has been in use by default for Qt on Windows and X11 since Qt-4.4, and basically removes the need for a widget to be backed by a native window handle. On Mac, this translates into Qt not having to use an NSView for each widget. Instead, we try to stick with just one view (the content view of the window), and divide that view into widgets ourselves, bypassing Cocoa as much as possible.

What we gain by doing this is three-fold; First, we remove the amount of code that needs to execute before an event reaches the application. For example, rather than Cocoa first finding the correct view for a mouse press, followed by Qt redirecting the event somewhere else (because of a grabs, popups etc), we now handle the press directly in Qt. Secondly, since more of the event handling is shifted from platform specific code, into platform independent code, we expect Qt/Mac to close the difference that may exist to other platforms over time. And finally, we now follow Apples recommendation of not using so many views. And they were right, that did actually slow down applications. The second movie below shows the same example using Alien, and the lag is totally gone.

Alien will be used by default on Mac (Cocoa) in Qt-4.8.

(Also, feel free to download and try Alien on Mac yourself)

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in C++, macOS, Performance


Beat Wolf says:

Thank you, such news are exactly what is needed currently to rebuild the confidence in Qt.

Will Stokes says:

Wow, this looks great. Since I do have some fancy UI’s with a *LOT* of widgets I’m optimistic this will be a huge improvement for me. There is one gotcha, I’m still using Qt/Carbon to support older Mac users of mine. Will this change only be made to Qt/Cocoa? 🙁

Alan says:

Nice! So, when can we expect Qt 4.8? 🙂

Robert Knight says:

Hello Richard,

Thanks for the update. Improved performance is always welcome 🙂

How will this work when an interface mixes Qt widgets with native Cocoa controls? We use Cocoa controls in a number of places in our Qt app to better match other Mac applications – since Mac users and UI designers are very sensitive to this.

My Name is Your Name says:

Thank you!

Fianally more focus on QT Desktop

David says:

I had an app that used a lot of widgets (a musical app with lots of knobs, faders, etc) and this will sure come in handy.

Richard Moe Gustavsen Richard Moe Gustavsen says:

@Will: Yes, this will only affect Qt/Cocoa. We are not implementing new features for the Carbon port anymore.
@Robert: The way Alien works, is that if you call QWidget::winId() on a widget (like you would have to do to mix native Cocoa controls), we “fall back” to create an NSView to back the widget up like before. So this will just work.

Great stuff! Thanks for this improvement. Both the performance gains and the more common behavior across platforms are big wins.

Philippe says:

Very interesting and extremely happy to see some OSX core work. I understand you only care about NSView, but do you know if HIViews cause so much slowdown as NSView do?

Konstantin Tokarev says:

@Will: If you need to support PPC users, you can build universal binaries of Qt/Cocoa from sources. But it won’t work on Mac OS X 10.4.

David says:

Thank you guys 🙂 I’m not a Mac dev, just coding for windows, but seeing desktop improvement in Qt restores confidence 🙂
Thanks again and don’t give up 🙂

Trenton says:

Good work, Richard and Mac team! Hope it gives you guys the benefits you are out after!

@Philippe IIRC, HIViews have an upper limit too, but I think that it’s higher than Cocoa. Carbon has a lot of callbacks as well. Still, if you use common sense, this issue is easy to avoid.

It's alive! says:

Excellent! Good to see Qt for the desktop alive and kicking.

Frank Mertens says:

Whow! Thanks! Keep up the good work.

lou per says:

This is slightly off topic, but related to Qt support on Mac OSX being discussed in this post. Apple just released OSX 10.7 beta to developers. If you could provide some information on this blog (in a separate post) about Qt’s commitment and ongoing development efforts to supporting OSX 10.7 when it ships to customers, that would be really great.
The official Qt response at the OSX 10.6 release was not great to say the least, so I’m hopping for a better commitment for those of us shipping commercial Qt applications that the Qt Mac team is fully on it to insuring our Qt based commercial applications will run properly on OSX 10.7 when it ships this summer (not at some indeterminate point after that date).
Those of us shipping commercial applications based on Qt don’t have the luxury of promising our customers support for a new major OS release at some arbitrary future date, it needs to work properly the day Apple officially ships OSX 10.7 to customers.
On going updates about the status of Qt OSX 10.7 support, potential problems to be aware of, and being ready to hit the official release date with any required updates is really of key importance for mac commercial developers who depend on Qt in our shipping applications.

Jason says:

Fantastic! Very happy to see some OSX love.

Richard Moe Gustavsen Richard Moe Gustavsen says:

@lou per: We we have already started to download and test Lion, and we will of course make sure Qt works on this platform. IIRC, the reason we could not guarantee Qt’s quality on Snow Leopard, was that we know from experience that Apple can do last minute changes to the final release from the beta that might break things. Which means that we also need to some final testing against this release before we _officially_ can declare full support. But I do agree, the last time we had to wait for a minor release of Qt before we could give this, and that could be improved.

Henrik Hartz says:

@Alan We do not have a timeline for Qt 4.8, but it’s not _terribly_ far off.. (/me takes off his vague hat again)

Jeremy Friesner says:

Awesome! You have no idea how happy this makes me. I’ve been waiting literally *years* for alien widgets on Mac! :^D

Jeremy Friesner says:

Hmm, I must be missing something obvious. I downloaded the code at the provide link, like this:

git clone git://

… and ended up with what appears to be a 4.7.2 Qt codebase, with no Mac alien widgets. What did I do wrong?

Philippe says:

Yes, Alien widgets are great stuff under Windows, though be warnt about these issues:

Richard Moe Gustavsen Richard Moe Gustavsen says:

@Jeremy: do a git branch -r. You need to checkout the master branch.
@Phillippe: The same restrictions does not apply on Mac.

Uku says:

Because now it is Aliens, will have Mac style of controls for other platforms than Mac?
If I understand correctly now it is totally painted by Qt.

Commenting closed.

Get started today with Qt Download now