DIVE modes crash on 24bit (BGR3) screen surface

[rudi]

Testing the new QWindowSurfaces on an ATI Rage128 (SNAP forced to 24bit color depth) causes a crash. Actually there are two problems that lead to this:

1.) Direct frame buffer mode is not enabled.

Fix: Change line 770 in qwindowsurface_pm.cpp to:

FOURCC bestBufFormat = fourccScreenToBuffer(diveCaps.fccColorEncoding, diveUseFB);

and redetermine d->setup.fccSrcColorFormat in the constructor of QPMDiveWindowSurfaceFB (the parent class calls fourccScreenToBuffer() with isFB = false).

I suggest to remove the default value for "isFB" from fourccScreenToBuffer(), so that it's easier to see what is wanted when using this function. Also Q_UNUSED(isFB); can be removed.

After applying this change, direct frame buffer mode works. For performance test results see ticket #101.

2.) DIVE blit mode doesn't work

QT_PM_DIVE=BLIT still crashes on that particular setup. This appears to be a DIVE bug. The crash occurs in DiveBlitImage? (RGB3 -> BGR3) and looks very similar to our attempts to use 32bit source buffers. I have not found an easy fix for that - can Qt be forced to use an BGR3 surface instead of RGB3 ?

[Dmitry A. Kuminov]

Rudi, thanks for testing and for noticing the problem. I fixed 1) in r742, please check.

What about 2), there seems to be no way to make QImage use the BGR3 format so we cannot do anything about it but leave as is.

[Dmitry A. Kuminov]

Well, we can of course do manual mapping as we do with BGR4, but I don't really see the need: the RGB3 mode was chosen for the BGR3 screen by mistake anyway (which was fixed in r742); now BGR4 is used in such a case which should theoretically be faster.

[rudi]

r742 fixes problem 1). I'd consider Problem 2). as a "permanent restriction" and would suggest not to put further effort into that. Especially, since 24bit modes are relatively uncommon these days and the frame buffer approach now works.