GNOME Bugzilla – Bug 126710
Pixmap rendering broken
Last modified: 2011-02-04 16:16:32 UTC
There seems to be a serious regression in rendering a gtk_pixmap on a drawable in the latest version 2.2.4.1 from http://www.dropline.net/gtk/download.php In the previous 2.2 version which I used with dll's date 5-5-2003 the pixmaps look good. Now it looks like the bitmap mask is misaligned with the gdk_pixmap. It doesn't matter if a gdk_pixbuf or gtk_pixmap is used, nor whether the fileformat was xpm or png. It looks like the bug that plagued Gtk+ 1.2, only now it looks worse. Parts of the pixmaps are invisible, especially thin lines. It also occurs for pixmaps put in a clist column.
A minimal but complete sample program will make fixing this bug much easier and more likely to happen soon.
I have to shamefully admit that it was a configuration problem. Apparently copying the new dll's into the system directory still left a trace of old code, causing the problem. After deinstalling the library and reinstalling the newer one it worked.
Created attachment 21412 [details] sample test case
Well I was partly misled and it turns out to be a bug after all. There was a user who didn't experience this bug, but he has a different system: Windows NT 4. This made me think I made a mistake, but after removing all old dlls the problem persisted. I have Windows 2000. So this is peculiar, however the similar old pixmap bug in Gtk 1.2 also exhibited a different view between Windows 2000 and WindowsME. Attached is a test case. You can see the difference between the two XPM files and the PNG file. Perhaps you expect a test case in C, but I can't write that. Perhaps you've already installed GtkAda. The routine names are the same, so it should be easy to follow. Needless to say this is a "showstopper" for me for 2.2.4.1. The 2.2.2 version doesn't have this problem. Regards, Manuel
If you expect me to fix this, I *do* want a test case written in C...
That's a big bummer. I hoped the source was clear enough for you to reproduce it easily. Also because it worked ok before, you could perhaps compare the old and current versions of the routines in the testcase and see which change might have introduced the bug. My C knowledge is pretty marginal, so this may be naive to think. Would anybody who reads this be able to rewrite the test case in C?
Not sure if the attached test program exposes the same bug, but the bug made visible with it at least matches the subject. And it is one of my old friends (see bug #81895 which had a wrong fix for it;) It's again about end pixel drawing (which I thought would not be necessary on NT, but just checked it again with NT4 SP6 and win2k SP1 as well as win98) and apparently it is. The following patch should finally fix it ...
Created attachment 26545 [details] two ways to draw a pixmap (left is missing end pixels without patch)
Created attachment 26546 [details] [review] drawing the end pixel w/o being too clever ;-)
It looks like the same bug to me too. I just hope the fix doesn't reintroduce a problem on 9x/me. This bug has cost me a lot of time. As a workaround my installer now contains two different libgdk-win32 dlls, a new one for 9x/me and an old one for win2k. Had to figure out which combination of old and new dlls worked together...
*** Bug 130202 has been marked as a duplicate of this bug. ***
2004-05-02 Hans Breuer <hans@breuer.org> * gdk/win32/gdkdrawable-win32.c (draw_segments) : don't modify the passed in GdkSegment(s) in place, we may get them again to draw at the same place. Fixes bug #129095, bug #137177, ... (draw_segments) draw the end pixel again to get the pixmap mask right, fixes bug #126710, #130202