gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending.

[Dmitry Timoshkov]

Vincent Povirk <madewokherd at gmail.com> wrote:

> > I tested printing quite a bit of different documents with an application
> > I have here and all of them get printed correctly with the patch. Before
> > the printed pages were just blank. What do you think is better for a user?
> 
> It's not good if things work by coincidence in one case that's
> important to you, and then we can't fix other cases later (or we can't
> fix other cases without breaking yours).

I don't understand your objection, nothing prevents you from improving
my patch. Printing something is still better than printing nothing, consdier
this as adding a partial implemenation in the place of a stub. GdiAlphaBlend
is not supported by printers, that's a matter of the fact, using StretchBlt
for now is better than doing nothing and even not printing a FIXME or returning
an error to an application. Feel free to implement it differently, until that
my implementation is suffice for many applications.

> >> If neither of those things are possible, the best we can do is to do
> >> ALL of our drawing through alpha_blend_pixels (by using a GpGraphics
> >> without an hdc), compose the result internally, and blit the result
> >> with a mask based on the resulting alpha values when GdipFlush or
> >> GdipDeleteGraphics is called.
> >
> > Did you test it under Windows? Does it really do it that way?
> 
> I heard a rumor that native draws by reading screen bits and writing
> back modified screen bits. This is consistent with what I know about
> the GDI+ API (in particular, it seems to be the only way to fully
> control gamma correction, which the API allows). I have not made any
> attempt to verify this.

Obviously this can't work for a printer.

-- 
Dmitry.