Re: [AD] win: 16bit stretchblit to GDI.. colours wrong.

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> when i stretch blit a 16bit BITMAP to the desktop using..
>
> stretch_blit_to_hdc( myBitmap, hdc, 0, 0, w, h, 0, 0, w-10, h-10 );
>
> and i scale it down.. the colours are wrong.
>
> when enlarging (stretch up) to the GDI desktop everything appears
> correctly.
>
> when bliting the internal BITMAP* 16bit to the GDI (same res, no
> stretching) everything is OK.
>
> its just when scaling down.

The stretch_blit_to_hdc() function reads as follows:

void stretch_blit_to_hdc(BITMAP *bitmap, HDC dc, int src_x, int src_y, int 
src_w, int src_h, int dest_x, int dest_y, int dest_w, int dest_h)
{
   BYTE *pixels;
   BITMAPINFO *bi;

   bi = get_bitmap_info(bitmap, _current_palette);
   pixels = get_dib_from_bitmap(bitmap);

   StretchDIBits(dc, dest_x, dest_y, dest_w, dest_h, src_x, bitmap->h - src_y 
- src_h, src_w, src_h, pixels, bi, DIB_RGB_COLORS, SRCCOPY);

   free(pixels);
   free(bi);
}

so we essentially do nothing and rely on StretchDIBits. Now quoting the 
StretchDIBits entry from the Platform SDK:

"The StretchDIBits function copies the color data for a rectangle of pixels in 
a DIB to the specified destination rectangle. If the destination rectangle is 
larger than the source rectangle, this function stretches the rows and 
columns of color data to fit the destination rectangle. If the destination 
rectangle is smaller than the source rectangle, this function compresses the 
rows and columns by using the specified raster operation. "

The raster operation we use is SRCCOPY:

"SRCCOPY: Copies the source rectangle directly to the destination rectangle."

However, the entry also contains:

"ICM: Color management is performed. The color profile of the current device 
context is used as the source color space profile and the sRGB space is 
used."

So Windows may try to be smart and perform some transformation in the color 
space when compressing. I don't know how to workaround that.

-- 
Eric Botcazou