How does GDI+ decide which to use, alphablending or dithering?
-
Hey guys! Does any of you have an idea how GDI+ -when filling a rectangle or a region with a color that has an alpha component set- decides to use dithering instead of "real" blending? We are using a third-party library to generate PDF files. When using a printer DC as a "reference" to generate the PDF document, GDI+ seems to use "normal" color blending when filling an area with a translucent color, but when using a screen DC to do the same it "magically" decides to use dithering which produces a "less satisfying" result.
> 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 guys! Does any of you have an idea how GDI+ -when filling a rectangle or a region with a color that has an alpha component set- decides to use dithering instead of "real" blending? We are using a third-party library to generate PDF files. When using a printer DC as a "reference" to generate the PDF document, GDI+ seems to use "normal" color blending when filling an area with a translucent color, but when using a screen DC to do the same it "magically" decides to use dithering which produces a "less satisfying" result.
> 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.<
In many cases, the device driver determines how the GDI+ functions operate. The printer driver for your printer may not support alpha blending. You might try using a memory DC to build up your graphics, then blitting that to your printer DC.
-
In many cases, the device driver determines how the GDI+ functions operate. The printer driver for your printer may not support alpha blending. You might try using a memory DC to build up your graphics, then blitting that to your printer DC.
It's the other way around actually (read my original post again), when using the printer, i get alpha, when using a screen based DC, i get dithering, this is why i don't understand it, since i KNOW that i can use e.g. AlphaBlend[^] on the screen without any problems, or if i use GetDeviceCaps[^] on the screen DC i see that it supports blending. I kinda know that the capabilities of the device is -at least usually- determined by the driver "under" it, what i would like to know is what GDI+ does to come to the conclusion that the screen-based device is incapable of blending and thus resorts to "low quality" dithering.
> 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.<
-
It's the other way around actually (read my original post again), when using the printer, i get alpha, when using a screen based DC, i get dithering, this is why i don't understand it, since i KNOW that i can use e.g. AlphaBlend[^] on the screen without any problems, or if i use GetDeviceCaps[^] on the screen DC i see that it supports blending. I kinda know that the capabilities of the device is -at least usually- determined by the driver "under" it, what i would like to know is what GDI+ does to come to the conclusion that the screen-based device is incapable of blending and thus resorts to "low quality" dithering.
> 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.<
If you're getting dithering, then your bits per pixel may be set to less than 24 bits. Like I said, the device drivers do most of that work. GDI+ doesn't really make any decisions. I've never seen reliable results in alpha blending from GDI+. I avoid it and either write my own code to do it, or use OpenGL.