One of the steps is blitting from one offscreen surface to another one
using a source color key for transparency.
(Both surfaces are in videomemory).
On my development machine it all works fine.
I've run into the following problem:
On some other videocards or systems the transparent blit is 5 to 10
times slower, and takes a lot more CPU than non-transparent,
practically making the whole process infeasible. I'm not sure what
exactly causes this, and how to overcome it. The problem happens both
with black and white transparent keys.
I tried to query the for the DDCAPS, and in all cases the
DDCKEYCAPS_SRCBLT flag in dwCKeyCaps field is 1, which must mean that
hardware does support the source color key acceleration, isn't it?
Examples of videocards where it works fine:
NVidia GeForce FX 5200 (AGP)
NVidia GeForce 6200 TurboCache (PCI Express)
NVidia GeForce 4 MX 400 (PCI Express)
Intel 82945G Express chipset family (Onboard)
Examples of videocards where it works with bad performance:
NVidia GeForce2 MX 100/200 (AGP)
NVidia Quadro4 980 XGL (AGP)
The questions are:
1.What exactly is the difference between the systems that causes a
performance problem?
2.How can I get a certain indication of it? (some flag in DDCAPS?)
3.How can I overcome that problem? Am I doing something wrong (it
works fine on some systems, though!)
The code snippet that causes the problem looks like this:
DDBLTFX bltFx;
ZeroMemory(&bltFx, sizeof(bltFx));
bltFx.dwSize = sizeof(bltFx);
bltFx.ddckSrcColorkey.dwColorSpaceHighValue = m_transparentColor;
bltFx.ddckSrcColorkey.dwColorSpaceLowValue =
bltFx.ddckSrcColorkey.dwColorSpaceHighValue;
hr = m_pSurface1->Blt(&m_Rect1, m_pSurface2, &m_Rect2,
DDBLT_KEYSRCOVERRIDE, &bltFx);
thanx!