|
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. during a “hackathon” in Oslo this summer. 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: 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? 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./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!”» Posted by Adam Higerd
on Thursday, February 04, 2010 @ 18:30
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. » Posted by vohi
on Thursday, February 04, 2010 @ 18:36
Great work Anders, the “animated tiles” demo on those HD TV’s definitely looked good! » Posted by boulabiar
on Thursday, February 04, 2010 @ 18:43
is there any graphs showing performance gain between the two versions ? » Posted by Rapscallion von Volokak
on Thursday, February 04, 2010 @ 19:04
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. » Posted by scorp1us
on Thursday, February 04, 2010 @ 19:13
LOL. To sum up this thread so far “[performance] pics or it didn’t happen!” » Posted by Carina Denkmann
on Thursday, February 04, 2010 @ 20:18
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? » Posted by scorp1us
on Thursday, February 04, 2010 @ 20:53
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? » Posted by Donald Carr
on Thursday, February 04, 2010 @ 21:07
@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. » Reply from AndersBakken
on Thursday, February 04, 2010 @ 22:47
@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 @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). » Posted by No'am Rosenthal
on Thursday, February 04, 2010 @ 23:20
@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./blogs/2009/03/13/using-hardware-acceleration-for-graphics/). » Posted by Adam Higerd
on Friday, February 05, 2010 @ 00:32
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. » Posted by Carina Denkmann
on Friday, February 05, 2010 @ 00:53
@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. » Posted by No'am Rosenthal
on Friday, February 05, 2010 @ 01:12
@Carina: it’s a confusing name » Posted by scorp1us
on Friday, February 05, 2010 @ 04:16
@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: Maybe http://code.google.com/p/pxcore/ 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. » Posted by Cheung
on Sunday, February 07, 2010 @ 16:17
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: » Posted by Denis Oliver Kropp
on Tuesday, February 23, 2010 @ 21:55
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 ReplyClick here to make an anonymous comment, or click here to log in first |
|
|
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.