CDC::GetDeviceCaps, how to know if AlphaBlend is supported or not?
-
Hey folks! I am trying to find out if a DC supports AlphaBlend or not. I used GetDeviceCaps[^] with
SHADEBLENDCAPSand checked for theSB_CONST_ALPHAflag, however, it seems like it happens that the DC doesn't return this flag BUT AlphaBlend[^] still succeeds on it (and produces the expected result). Am i usingGetDeviceCapsthe wrong way? Is this not the way to check for the support? Is GetDeviceCaps simply not reliable? Thanks for any answers in advance.> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Hey folks! I am trying to find out if a DC supports AlphaBlend or not. I used GetDeviceCaps[^] with
SHADEBLENDCAPSand checked for theSB_CONST_ALPHAflag, however, it seems like it happens that the DC doesn't return this flag BUT AlphaBlend[^] still succeeds on it (and produces the expected result). Am i usingGetDeviceCapsthe wrong way? Is this not the way to check for the support? Is GetDeviceCaps simply not reliable? Thanks for any answers in advance.> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
How did you test for this - as a value or bit mask?
Unrequited desire is character building. OriginalGriff
-
How did you test for this - as a value or bit mask?
Unrequited desire is character building. OriginalGriff
Bit mask:
bool DCCanBlend = ((dc.GetDeviceCaps(SHADEBLENDCAPS) & SB_CONST_ALPHA)?true:false);
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Bit mask:
bool DCCanBlend = ((dc.GetDeviceCaps(SHADEBLENDCAPS) & SB_CONST_ALPHA)?true:false);
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Hey folks! I am trying to find out if a DC supports AlphaBlend or not. I used GetDeviceCaps[^] with
SHADEBLENDCAPSand checked for theSB_CONST_ALPHAflag, however, it seems like it happens that the DC doesn't return this flag BUT AlphaBlend[^] still succeeds on it (and produces the expected result). Am i usingGetDeviceCapsthe wrong way? Is this not the way to check for the support? Is GetDeviceCaps simply not reliable? Thanks for any answers in advance.> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
Hey Code-o-mat, As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] :) Best Wishes, -David Delaune
-
Hey Code-o-mat, As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] :) Best Wishes, -David Delaune
Thanks for the reply. I read that but my DC!s are (sometimes) for printers. However, to save on paper/ink money i am using a few "virtual" printers (like Cute PDF Writer) to print to files. Maybe these virtual drivers! DC will "function" as a screen DC rather than a printer DC when drawing onto, i will check that (with GetDeviceCaps + TECHNOLOGY) and report back what i have found.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Check the remarks section here[^].
Unrequited desire is character building. OriginalGriff
Thanks for your reply. As i also said to
Randor, my DCs are for printers, but to avoid vasting ink and paper i am -at least initially- working with virtual printers which print to a file like PDF. Can be that these work as screen DCs and not printer DCs, i will check into that (using GetDeviceCaps and TECHNOLOGY) and "report back".> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Hey Code-o-mat, As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] :) Best Wishes, -David Delaune
So i did some testing and all the virtual printer drivers say they are
DT_RASPRINTER. None of them report to support AlphaBlend but by forcing them to use AlphaBlend anyways some of them succeed. Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Check the remarks section here[^].
Unrequited desire is character building. OriginalGriff
They all report
DT_RASPRINTER.> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Thanks for the reply. I read that but my DC!s are (sometimes) for printers. However, to save on paper/ink money i am using a few "virtual" printers (like Cute PDF Writer) to print to files. Maybe these virtual drivers! DC will "function" as a screen DC rather than a printer DC when drawing onto, i will check that (with GetDeviceCaps + TECHNOLOGY) and report back what i have found.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
Hey Code-o-mat, Sorry about the late reply... I was out of the office today. One thing that I have learned over the years is that printer drivers often report incorrect capabilities. Generally there is not much that can be done about these edge cases. I've had similar experiences to yours when dealing with virtual device drivers. Best Wishes, -David Delaune
-
So i did some testing and all the virtual printer drivers say they are
DT_RASPRINTER. None of them report to support AlphaBlend but by forcing them to use AlphaBlend anyways some of them succeed. Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
Code-o-mat, The author of the printer driver reports the device capabilities. And because everyone's cousin and grandma is a software engineer these days... using software is like a box of chocolates... you never know what your gonna get.
Code-o-mat wrote:
Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
Bit-block transfers are suppose to be a two-way street. When you call BitBlt on a printer device context... the win32 subsystem performs some internal magic and then end up calling the printer drivers DrvBitBlt function[^]. If the device driver does not implement DrvBitBlt... it uses the default EngBitBlt function[^] (This is what the Gdi32 BitBlt uses via SYSCALL... it forwards to win32k.sys!NtGdiEngBitBlt) Come to think of it... this is probably why some of the virtual printer drivers you are testing support alpha blending... the driver probably does not implement DrvAlphaBlend [^]so it ends up calling the EngAlphaBlend function[^]. Maybe you should consider giving your employer or users the option of using an open-source virtual printer such as Virtual Image Printer[^]. At least you would have some consistency. I've been through similar battles with virtual USB, virtual serial and virtual printer drivers. I am very happy that Microsoft is forcing x64 device drivers to be signed. Unfo
-
Code-o-mat, The author of the printer driver reports the device capabilities. And because everyone's cousin and grandma is a software engineer these days... using software is like a box of chocolates... you never know what your gonna get.
Code-o-mat wrote:
Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
Bit-block transfers are suppose to be a two-way street. When you call BitBlt on a printer device context... the win32 subsystem performs some internal magic and then end up calling the printer drivers DrvBitBlt function[^]. If the device driver does not implement DrvBitBlt... it uses the default EngBitBlt function[^] (This is what the Gdi32 BitBlt uses via SYSCALL... it forwards to win32k.sys!NtGdiEngBitBlt) Come to think of it... this is probably why some of the virtual printer drivers you are testing support alpha blending... the driver probably does not implement DrvAlphaBlend [^]so it ends up calling the EngAlphaBlend function[^]. Maybe you should consider giving your employer or users the option of using an open-source virtual printer such as Virtual Image Printer[^]. At least you would have some consistency. I've been through similar battles with virtual USB, virtual serial and virtual printer drivers. I am very happy that Microsoft is forcing x64 device drivers to be signed. Unfo
Guess i will just have to live with it. :( Thanks. I tried blitting from the printer device (it reported it supports it) but all i get is blackness. This complicates my life a lot... :(
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<
-
Hey Code-o-mat, As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] :) Best Wishes, -David Delaune
actually in XP the GetDeviceCaps returns support for acceleration (3=SB_CONST_ALPHA|SB_PIXEL_ALPHA). In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
-
actually in XP the GetDeviceCaps returns support for acceleration (3=SB_CONST_ALPHA|SB_PIXEL_ALPHA). In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
Hi, Sorry about the late reply. It's the Thanks Giving holiday here. It has also been 7 years since I wrote the above comment which appears to be completely correct.
arnoudmulder wrote:
In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
I believe that this CDC::GetDeviceCaps behavior over "Remote Desktop" is because your code is not using the physical hardware display driver. I believe over RDP you are actually using the "RDP Encoder Mirror Driver" object located at (%WinDir%\system32\drivers\rdpencdd.sys) which does not have hardware acceleration. In other words... the return value from CDC::GetDeviceCaps is correct. Best Wishes, -David Delaune