Menu
▾
▴
#2275 tkWinDraw transparent bitmap problem and fix
closed-accepted
8
2007-11-07
2007-05-22
No
XCopyPlane in tk/win/tkWinDraw.c is used to draw
bitmap images. For some image types SetBkColor and
SetTextColor are set. For bitmap images with a
transparent background (case 2 in the code), the
SetBkColor and SetTextColor are not set. But those
settings can affect the output of transparent images,
in ways that are not clearly documented in MSDN.
The problem is not always seen. It does not seem to
affect tcl/tk core widgets which almost always draw
via an off-screen pixmap. But the tktable extension
legitimately draws directly to the on-screen window
for performance, and can get often get corrupted
transparent bitmaps - it also seems to depends on the
type of wish build, what has been drawn previously,
the state of ms-windows, day of the week etc.
The attached tktable-bitmap1.tcl script demonstrates
the problem using tktable. The second bitmap is
supposed to be a red square with rounded corners, but
on my system is displayed reversed.
The fix is simply to reset BkColor and TextColor for
transparent bitmaps, as shown in the following patch.
Note that the background/foreground settings are
counter-intuitive.
--- tkWinDraw.c Tue May 22 11:37:46 2007
+++ tkWinDraw-update.c Tue May 22 11:38:07 2007
@@ -415,11 +415,14 @@
/*
* Case 2: transparent bitmaps are handled by setting the
* destination to the foreground color whenever the source
- * pixel is set.
+ * pixel is set. We need to reset the BkColor and TextColor,
+ * because they affect bitmap colour mapping.
*/
fgBrush = CreateSolidBrush(gc->foreground);
oldBrush = SelectObject(destDC, fgBrush);
+ SetBkColor(destDC, RGB(255,255,255));
+ SetTextColor(destDC, RGB(0,0,0));
BitBlt(destDC, dest_x, dest_y, width, height, srcDC, src_x, src_y,
MASKPAT);
SelectObject(destDC, oldBrush);
I'll attach updated source files for the current CVS
HEAD and core-8-4-15 branches. I have been using the
fix with tk8.14 for several weeks with no problems.
script to demonstrate problem using tktable
updated source for CVS HEAD
Logged In: YES
user_id=883691
Originator: YES
File Added: tkWinDraw-head.c
updated file for 8-4-15 branch
Logged In: YES
user_id=883691
Originator: YES
File Added: tkWinDraw-8.4.15.c
Logged In: YES
user_id=72656
Originator: NO
I see no effect with this patch applied using the demo for 8.4-branch.
Logged In: YES
user_id=883691
Originator: YES
Well I see a difference :-)
I attach a screenshot.
I think that this is basically an uninitialised state problem, so where that state is obtained from and what it contains is anyone's guess, but it could well depend on the type of tcl/tk build etc.
I have just tested a clean tcl/tk 8.4.15 build, using Visual Studio 2003, with the distribution makefile.vc. Default configuration, no options i.e. not threaded or anything. This is my normal build method:
d:\src\tcl8.4.15\win> nmake -f makefile.vc release
d:\src\tcl8.4.15\win> nmake -f makefile.vc install INSTALLDIR=d:\tcl
d:\src\tk8.4.15\win> nmake -f makefile.vc release TCLDIR=d:\src\tcl8.4.15
d:\src\tk8.4.15\win> nmake -f makefile.vc install TCLDIR=d:\src\tcl8.4.15 INSTALLDIR=d:\tcl
I also build tktable using it's makefile.vc.
Running the tktable-bitmap1.tcl script the problem is present as shown in the screenshot.bmp, and fixed by the patch.
File Added: screenshot.bmp
screenshot of problem
Logged In: YES
user_id=72656
Originator: NO
Can you confirm whether you see the same issue using ActiveTcl 8.4.14 and/or 8.5 on your machine? I want to know whether this may be a compilation issue, or a system-particular issue.
Logged In: YES
user_id=883691
Originator: YES
I've downloaded and tested ActiveTcl 8.4.14 and it doesn't display the problem.
Trying different complation options with win\makefile.vc I've found that the threaded build masks the problem i.e.:
d:\src\tcl8.4.15\win> nmake -f makefile.vc release OPTS=threads,thrdalloc
d:\src\tcl8.4.15\win> nmake -f makefile.vc install OPTS=threads,thrdalloc INSTALLDIR=d:\tcl
etc., is ok.
Probably other options could give different behaviour as well, as we have an uninitialised drawing state problem. MSDN is not detailed in describing the effect of the SetBkColor and SetTextColor, but it does say "The background color is also used when converting bitmaps from color to monochrome and vice versa." (See http://msdn2.microsoft.com/en-us/library/ms534861.aspx\). The XCopyPlane code is doing a monochrome bitmap transfer to a color window, but the SetBkColor and SetTextColor values are not explicitly set. To be robust they should be. Otherwise we are presumably picking up some uninitialised or left over values on the HDC.
Logged In: YES
user_id=202636
Originator: NO
In non-threaded mode I believe we use a class DC. This doesn't occur in threaded mode. So in non-threaded there is much more opportunity for contaminating the DC with other settings. Applying this patch doesnt cause any trouble in the demos or apps I tested (tkchat).
Applied to HEAD
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).