Melwyn, On Fri, 2010-05-07 at 15:48 +0530, Melwyn Lobo wrote: > compiling Qtopia 4.6.2 and using DirectFB as Gfx driver.... I tested > this release on our platform containing an SH4 processor and 2d > blitter using underlying hardware acclerated graphics functions in > Directfb.
I hope with stgfx2 :-) > 2. For a UMA system with system memory acting as framebuffer, what are > benefits when choosing DSCAPS_VIDEO while creating a surface. Is this > surface present on the framebuffer or elsewhere? Using DSCAPS_VIDEO, you force DirectFB to allocate from framebuffer memory. Otherwise DFB might decide to use system memory, via simple malloc(). As most blitter acceleration hardware, including the BDisp, can only access physically contiguous memory, which you don't get via malloc(), you specify DSCAPS_VIDEO to prevent surfaces from potentially ending up in linux system memory. In addition, DirectFB may decide to swap surfaces into and out of video/system memory, but that usually is unwanted behaviour, DSCAPS_VIDEO prevents that from happening as well. > 3. While blitting an updated rectangle, is there an implicit back > buffer in DirectFB where this rectangle is first copied before the > entire surface is blitted to the framebuffer. That really depends on how the surfaces and primary were created, i.e. what the application does. Don't know about QT. > 4. I did not use the fusion kernel module from DirectFB for running > this QT app. In which use case is it useful and what is its purpose? Using fusion, you can run multiple independent DirectFB applications at the same time. The same holds true for QT applications when QT uses DFB as a back end. HTH, Andre' _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
