Qt 4.6, now with improved DirectFB support!

As of Qt 4.6 massive improvements have been made to the QWS/DirectFB driver.

While there has been some support of DirectFB since Qt 4.3, 4.6 comes with significant improvements in terms of performance, stability and features. This release has been validated on several media platforms in the home entertainment sphere like DTVs, set-top boxes and Blu-Ray players. We even got the code reviewed by Denis Oliver Kropp of www.directfb.org during a “hackathon” in Oslo this summer.

http://www.directfb.org

DirectFB is an open source project that provides an abstraction on top of proprietary graphics hardware acceleration. It has proven to be particularly successful on embedded systems that provide specialized 2D/video playback acceleration. It is the de-facto standard on internet-connected HD TVs and set-top boxes that run Linux. From Qt’s perspective it provides a nice way to abstract out proprietary interfaces. We’ve achieved animations with upwards of 30 fps on High Definition resolutions (1080/720) mass-market hardware.

Qt uses DirectFB for the following operations:
- Access to hw-accelerated blitting and paint operations (QPainter)
- Video memory buffer management and image decoding(QPixmaps)
- Window composition/management and synchronization with screen refresh rates (QWS)
- Input device events (keyboard/mouse/joystick/touchscreen/remote control) (QEvents)

Planned features in future releases include support for NPAPI plugins (Flash) and better integration with the native DirectFB window management.

- Do you use Qt/DirectFB?
- Would you want to use multiple processes painting to the screen concurrently?
- Do you have feature or documentation requests?
- Do you have bug-reports?

We would love to hear from you! Please report via the normal support channels.

For more technical details on the QWS/DirectFB driver consult:

http://doc.trolltech.com/4.6/qt-embeddedlinux-directfb.html

This contains debugging and profiling aids as well as best practices guidelines. You can explicitly profile when painting operations are accelerated or when they fall back to the underlying raster engine

17 Responses to “Qt 4.6, now with improved DirectFB support!”

I am currently trying to ascertain which engines are is fastest, and under which scenarios.

It would be really awesome if you could post X(accelerated)/ X(DirectFb) / DirectFb / Windows benchmarks.

Thanks.

I’ve used Qt/QWS before and I’ve been wondering how it compares to Qt/DirectFB. Among other things, it’d be nice to be able to use DirectFB-enabled apps alongside Qt/E apps.

Feature requests, though… QWS is dramatically lacking in useful window management routines. Among other things, there’s no documented way to raise or hide a window.

Great work Anders, the “animated tiles” demo on those HD TV’s definitely looked good!

is there any graphs showing performance gain between the two versions ?

Do you know of any widely/freely available reference platforms external people can purchase to validify your work to date or to quantify the performance gains garnered from using DirectFB. Like the Beagle board for instance, any chance of getting that accelerated through DirectFB?

Graphs of best case gains would also be invaluable as a metric for people to strive for.

LOL. To sum up this thread so far “[performance] pics or it didn’t happen!”

Since I do not use embedded Qt, I don’t have any bugs to report of features to suggest. Once thing I wonder, though, is how a standard Linux system (say with i945 chipset) would perform when avoiding X.org, intel drivers, and KWin, and just replacing it with a DirectFB & QWS combo.

In other words, is it possible to run QWS on non-embedded systems?

Carina: Your “In other Words” statement doesn’t make sense. If you ran it on non-embedded systems, you’d you’ll be running on top of *something*. GDI, DirectX, X, etc.

You could however run QWS on a non-embedded system if your OS could give it a surface to write to. This would be like a “virtual frame buffer” of which there are some. You can have apps use a VFB, then use a utility to display the FB content, locally or remote. Would this be what you’re asking for?

@Carina: I thinks Anders request for features/bugs pertains to the DirectFB specific Qt/Embedded driver.

In answer to your question, there is no reason you could not run Qt/Embedded applications on a desktop machine using DirectFB. The only thing you need is to get an accelerated DirectFB driver which utilizes your desktop hardware, and therein lies the rub as I am not aware of any mainstream GPU vendors (Nvidia/Intel/AMD) who ship accelerated DirectFB drivers. Given the existence of an adequate driver, the running of a single dedicated Qt/DirectFB application (such as a monolithic set-top box software stack, eg Boxee) would be trivial. I would personally not want to try to run all of KDE against Qt/Embedded, and would image that the kwin/QWS integration task would require a fair amount of effort and, above all else, hackery.

@Adam Higerd

To be quite frank QWS and DirectFB are sort of fighting one another. There’s a lighthouse plugin for DirectFB in the works which arguably is a lot nicer fit. While you conceptually might be able to run a QApplication::GuiClient app against a QApplication::GuiServer that runs DirectFB this really isn’t tested or supported. If you want a multi app system you’d want DirectFB to handle the multi-application aspects of it and you’d want to run both as a server (-qws). (There are some known bugs regarding this however since I believe apps would receive all events regardless of which one is active)

@Volker

Thanks I’ll see if I can conjure up some videos.

@scorp1us/boulabiar

I’ll see if I can get some graphs. The problem is that it’s hard to get an apples to apples comparison here. DirectFB/X11 really is just a simulation engine a la QVFB and while it has the potential to backend to OpenGL is not a particularly good measurement of anything. If a board has OpenGL on it it very rarely has DirectFB.

@Rapscallion

Internally we’ve used platforms from atleast NXP/Sigma Designs/Broadcom.

@Carina

scorp1us answered this one pretty well. While I haven’t tested it myself I believe a system that skips X11 to have DirectFB own the framebuffer likely will benefit the real gains come when using a properly hw accelerated interface. E.g. on your desktop machine there might be a functional accelerated driver but it’s probably using OpenGL internally which would be just as good (or better).

@Rapscallion: Note that DirectFB is mainly optimized for old-school blitter/alpha-blending hardware, while the boards that are publicly available for hacking are usually of programmable-3D class (see Tom Cooksey’s blog from a year ago, http://labs.trolltech.com/blogs/2009/03/13/using-hardware-acceleration-for-graphics/).
So even though there is a DirectFB driver that works on the Beagle board and N900, for example, it won’t tell you much about “DirectFB performance” on hardware that’s actually relevant to the DirectFB APIs. DirectFB and OpenGL are just APIs - the real comparison is DirectFB vs. raster on blitter/alpha-blending hardware, which sometimes doesn’t even support /dev/fb.
I’ll let Anders deal with the graphs, but from what I’ve seen so far we’re talking about ~1-5 FPS without DirectFB vs. ~25-30FPS with DirectFB, on specific types of hardware with a specific type of animation.

It’s perfectly possible to run Qt/embedded on x86 hardware and give it full control over the framebuffer. I was working on a toy desktop environment based around that entire idea for a while, and it actually worked reasonably well — I had Arora, QSciTE, and a console program I found on qt-apps.org, so I basically had everything I needed for a basic netbook. It ran pretty well, but it was unaccelerated so things like scrolling in Arora were sluggish.

@scorp1us, from what I understand, DirectFB means “direct access to framebuffer”, so I would not need anything to run it on (besides a /dev/fb device)? Correct me if I am all wrong.

But from the other comments, those kernel drivers are not accelerated at all, so my question about “how would it perform” is already answered.

@Carina: it’s a confusing name DirectFB is a specific acceleration mechanism (www.directfb.org), and by all means different from direct pixel access to /dev/fb.

@Carina, if you want to run QWS at the same time as a regular desktop environment, then you only need to assign a chunk of memory of XxYx(BPP/8) for use as a frame buffer. Then tell the framebuffer software the size and address where that chunk of memory is, then you can use the QWS system.

See:
http://en.wikipedia.org/wiki/Framebuffer
http://doc.trolltech.com/2.3/qvfb-qws.html
http://thelins.se/learnqt/category/embedded-linux/

Maybe http://code.google.com/p/pxcore/
http://wiki.tcl.tk/12694

But you won’t have DirectFB. At best you’ll just get a window on whatever DE you already have, where it runs the QWS, like remote desktop or VNC.

Very good news for platforms that lack OpenGL support!

I think that making QImage backed by a directfb surface would be great. The only difference would be that the memory is Lock()-ed from the directfb surface, instead of from malloc(). The benefits are that drawImage() is accelerated, and conversion from/to QPixmap is a lot cheaper. The trade-off is that accessing video memory is slower than system memory, so drawing to a QImage would be a bit slower. But QImage are likely to be used in threaded rendering, which is less critical than drawImage() in the GUI thread, IMHO.

I also think that implement a QWS backend with directfb windows is not necessary. First of all, not that directfb windows are not good, but QWS has been around for years and it works great. Just replacing the chunks of memory of framebuffer with directfb (sub)surfaces should be sufficient. Why change something that ain’t broken? Not to mention that you can keep consistency across different QWS backends by only introducing minimum changes.

Second of all, from the following thread, directfb windows are backed by system memory:
http://www.mail-archive.com/directfb-users@directfb.org/msg08702.html
So directfb windows are not accelerated on platforms that don’t support blitting from/to system memory.

First of all, thanks to Anders for the nice article!

Regarding DirectFB window surface storage, they are handled like any other surface and will be stored in graphics accelerator memory if feasible.

And yes, the name is quite confusing, suggestions welcome

DoK

Leave a Reply

Click here to make an anonymous comment, or click here to log in first