Sebastian Lackner sebastian@fds-team.de writes:
On 07.02.2017 17:08, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
@@ -2627,14 +2627,12 @@ BOOL CDECL X11DRV_UpdateLayeredWindow( HWND hwnd, const UPDATELAYEREDWINDOWINFO { IntersectRect( &rect, &rect, info->prcDirty ); memcpy( src_bits, dst_bits, bmi->bmiHeader.biSizeImage );
PatBlt( hdc, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, BLACKNESS );
- }
- ret = GdiAlphaBlend( hdc, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
info->hdcSrc,
rect.left + (info->pptSrc ? info->pptSrc->x : 0),
rect.top + (info->pptSrc ? info->pptSrc->y : 0),
rect.right - rect.left, rect.bottom - rect.top,
(info->dwFlags & ULW_ALPHA) ? *info->pblend : blend );
- }
- ret = BitBlt( hdc, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
info->hdcSrc,
rect.left + (info->pptSrc ? info->pptSrc->x : 0),
rect.top + (info->pptSrc ? info->pptSrc->y : 0),
SRCCOPY );
BitBlt is not guaranteed to set a valid alpha channel.
Could you please clarify in which situation this code will not work as expected? I have checked the relevant code, but so far I have not found any reason why it wouldn't work here. Also, it works perfectly fine with the test app written to demonstrate this bug (which also uses alpha channels). Am I missing something?
If the source doesn't have alpha, it's assumed to be all 0xff. In that case, GdiAlphaBlend will set the alpha correctly in the destination, but BitBlt won't.