The Qt/S60 port is currently using Qt's raster graphics system which means that in this case QPixmap is using a QImage internally to store the rasterized data. So basically the performance difference here is neglible.
QImage is the class that gives you a pointer to the internal data though and let's you write pixels directly whereas QPixmap does not have this functionality because the idea is that the data could potentially be owned by a window manager on the various platforms and potentially stored in graphics memory. So QImage is the class you want to use (you can use QPixmap::fromImage() after if you really want a QPixmap).
Basically it does something like this (I didn't test this, but should work):
Code:
cfbsBitmap->LockHeap();
TDisplayMode mode = cfbsBitmap->DisplayMode();
// Add a switch case here to map a TDisplayMode -> QImage::Format
QImage::Format format = ...;
TSize bitmapSize = cfbsBitmap->SizeInPixels();
// This is the QImage that will hold the CFbsBitmap
// Next line will malloc (width) X (height) X (depth) bytes.
QImage image(bitmapSize.iWidth, bitmapSize.iHeight, format);
if (!image.isNull()) {
// Copy the data from 'src' to 'dest'
const uchar *src = (const uchar*)cfbsBitmap->DataAddress();
uchar *dest = image.bits();
Mem::Copy(dest, sptr, image.numBytes());
} else {
// Didn't get memory, deal with it.
}
cfbsBitmap->UnlockHeap();
Depending on the use case, you might be able to get away with not copying the data, but leaving the FBSERV in the locked state for an extended period of time is a bad idea.