reassign 329231 kst found 329231 1.1.0-2.1 thanks Mark,
I just spent some time investigating this bug, and here is what I found: The two line change you propose to revert in qt is the only change in qpixmap.cpp or qpixmap_x11.cpp from qt 3.3.4 to 3.3.5. In the changes file <http://www.trolltech.com/developer/changes/changes-3.3.5.html> I read this: - QPixmap Fixed a crash when loading a cursor from an embedded image. The color depth is now set properly when converting a QBitmap. Even though this is in the "Mac" section of the changes file, this makes me reluctant to revert the change. When I look at the qt 3.3 API docs for QPixmap constructors <http://doc.trolltech.com/3.3/qpixmap.html#QPixmap-3>, I read: The depth can be either 1 (monochrome) or the depth of the current video mode. If depth is negative, then the hardware depth of the current video mode will be used. Finally, I ran kst under gdb with qt-x11-free-dbg installed and set a breakpoint at QPixmap::init just before creating a plot. After lots of continues with valid parameters (w or h is 0 and depth is 0, or depth is -1 or 24 on my display), I got one with depth set to 8. This doesn't cause a problem here because w = h = 0, so a null pixmap of depth 8 is created. When it is resized, however, it causes a problem. With the old qt behavior, an invalid depth was ignored when creating a null pixmap. So, the bug is in lines 84, 124, 389 of kst/kst/kst2dplot.cpp where it specifies a depth of 8 when creating the KstBackBuffer. It should probably use the default of -1 and let qt create a QPixmap of the appropriate bit depth. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
