From: SourceForge.net <no...@so...> - 2006-05-26 20:13:51
|
Bugs item #456299, was opened at 2001-08-28 14:26 Message generated for change (Settings changed) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=456299&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 13. Win Menus Group: obsolete: 8.4a2 >Status: Closed >Resolution: Duplicate Priority: 7 Submitted By: D. Richard Hipp (drh) Assigned to: Mo DeJong (mdejong) Summary: Distorted images in Win2000 menus Initial Comment: This bug occurs on Win2000 only. WinNT, WinME, Win98, and Win95 (and of course Unix) all appear to work correctly. When a menu entry is an image instead of text, the first time the image is drawn it is distorted. It appears as if the clip mask is offset up and to the left by 3 pixels. The distortion appears only when the menu first pops up. If you drag the mouse over the menu entry with the image, the image is repainted and is drawn correctly. The following script is sufficient to reproduce the problem: image create photo img4 -data { R0lGODlhEQAeAPEDAAEBAQAz/////wAAACH5 BAUAAAMALAAAAAARAB4AAAJjnAepeqcCo2Am yQsTArivD4ZiiDRlA5Sp6pzr2aLm+tJmFcN3 yus3+/o5NMJd8XgLIE1KQ6CZfD4Hyun0UKVq qdWmd4vNbrtMJ9R6baC5SOlSWNtUiDhcr24H 4lu2+8xFQ1QAADv/ } menubutton .b -text {Press Me} -menu .b.m1 pack .b menu .b.m1 -tearoff 0 -background white \ -activebackground white .b.m1 add command -image img4 -command exit ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2006-05-26 13:13 Message: Logged In: YES user_id=72656 see also 1329198 ---------------------------------------------------------------------- Comment By: Sébastien BARRE (sebbarre) Date: 2006-03-09 14:17 Message: Logged In: YES user_id=214100 This bug actually happens not just on 2000, but XP as well, and is also open here, with test script and screenshots: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1329198&group_id=12997 ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-01-05 14:04 Message: Logged In: YES user_id=32170 A bit of testing shows it has indeed _not_ been fixed. I don't understand the code enough, at all, but it does sound similar -- if Tk_RedrawImage is where the problem occurs, then perhaps some dc adjustment in tkWinDraw.c/TkPutImage is needed? ---------------------------------------------------------------------- Comment By: Mo DeJong (mdejong) Date: 2004-01-05 10:34 Message: Logged In: YES user_id=90858 Well, I don't think so. The change I made was in DrawWindowsSystemBitmap and that method does not seem to be used in the Image drawing code. The thing is, this sounds like the same bug that I was running into. The problem was that DPtoLP was returning coords that were strangely scaled down when the menu was first posted. The Tk menu code deal with images by calling Tk_RedrawImage and I don't see any other calls to DPtoLP in the win subdirectory, so I think it is a safe bet that this bug is not fixed. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-01-05 07:39 Message: Logged In: YES user_id=32170 Mo -- Wondering if your recent tkWinMenu.c changes impact this long-standing bug? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-03-04 18:40 Message: Logged In: YES user_id=72656 This was not addressed for 8.4.2. ---------------------------------------------------------------------- Comment By: Damon Courtney (damonc) Date: 2003-03-04 18:21 Message: Logged In: YES user_id=50387 This bug still occurs in 8.4.2 on Windows XP (and probably still on 2k). Was there every anything done to remedy the problem? ---------------------------------------------------------------------- Comment By: Todd Helfter (tmh) Date: 2001-10-04 09:37 Message: Logged In: YES user_id=92123 As the volunteer for Win and Unix menus, I would be happy to review any code changes that are submitted. I cannot pretend to know how Windows menus work. Let me know what more I can do to help. I will try the test script above. Todd (tmh) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-04 09:06 Message: Logged In: NO Looked through the code and did a bit of debugging and realised that most of what I wrote before isn't too relevant. However, it is odd that this stuff works for bitmaps but not for images. Images end up in 'XCopyArea' (tkWinDraw.c) and bitmaps end up in 'XCopyPlane'. Both of these functions use 'BitBlt' (the latter uses it in a variety of more complex ways). Perhaps a workaround would be not to use 'Tk_RedrawImage' to draw to the screen, but instead to draw on a new Drawable and then copy that onto the screen using XCopyPlane (or just find out what it is in XCopyPlane that is making BitBlt work)... random thoughts anyway.... ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2001-09-29 03:29 Message: Logged In: YES user_id=32170 I don't know much about Win32 or the technicalities of these internals of Tk, but looking at the code I see one potential anomaly. First of all, bitmaps and text display correctly, it is only images that have a problem. If I look at 'DrawMenuEntryLabel' in tkWinMenu.c, I notice that bitmaps and text both pass on the 'gc' to the drawing routines where it is used to do things like 'OffsetClipRgn' (this rings a bell with drh's message below). However, to draw an image, Tk_RedrawImage is called, and it doesn't receive the gc passed to 'DrawMenuEntryLabel', so if that gc contains any useful information about offsets, it clearly won't be used. Does the above make sense to anyone who understands this better? ---------------------------------------------------------------------- Comment By: Peter Spjuth (pspjuth) Date: 2001-09-29 01:54 Message: Logged In: YES user_id=98900 The same effect happens on Win98 if "Animate menus" is turned on. Might be related to [219940] [220760] et. al. The checkbutton problem was solved by [220760] in tkWinMenu.c rev 1.13. ---------------------------------------------------------------------- Comment By: D. Richard Hipp (drh) Date: 2001-09-28 18:10 Message: Logged In: YES user_id=69293 I spent a whole day trying to fix this problem. What I found was that the BitBlt() system call does not work correctly in Win2K immediately after the receipt of a WM_DRAWITEM message for user drawn menus. This is, I believe, a bug in Win2K. The clip mask is offset by 3 pixels, which is also the width of the border around the menu. I doubt that is a coincidence. The only workaround I can think of is to delay the redraw of menus until sometime after the WM_DRAWITEM has occurred. Perhaps the WM_DRAWITEM can trigger an idle callback to do the drawing. That won't be as simple as it sounds, I fear, since the normal event loop appears to be disabled during menu drawing under windows. Perhaps someone who actually understands the windows menu code in Tk can provide more help... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-09-28 17:46 Message: Logged In: NO Verified bug still there in 8.3.3 and 8.4a4 on Windows 2000. The same bug affects all images in menus (including those images shown with the -compound option in my recent TIP). Also verified that the workaround in the message below does work. Anyone know a real solution to this problem? ---------------------------------------------------------------------- Comment By: D. Richard Hipp (drh) Date: 2001-08-29 07:11 Message: Logged In: YES user_id=69293 On the Win2K properties dialog box (which you bring up by right-clicking on the root window) under the "Effects" tab, if you turn off the Visual effect named "Use transition effects for menus and tooltips", then the problem goes away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=456299&group_id=12997 |