[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||4 - High, e.g. key functionality not working|
|Scope:||2 - Specific to an operating system|
|Summary:||fl_draw_pixmap does not work with Quartz under MacOS X 10.5|
|Fix Version:||1.1-current (SVN: v6026)|
Trouble Report Files:
Trouble Report Comments:
07:34 Jan 14, 2008
|When using fl_draw_pixmap, the image is not drawn correctly on the screen. Either nothing is drawn or only a square of the right size but filled with a solid color is shown. But the function spends long time to do this. This problem seems to be specific for MacOS X when fltk is compiled for Quartz, not for QD. |
Note that drawing a pixmap image using Fl_Pixmap::draw works correctly and quickly. Declaring a Fl_Pixmap object and drawing it does NOT produce the problem mentioned above.
I observed this bug under MacOS X 10.5 and have no more chance to try earlier versions. In ealier versions, I used QD or changed the configure script to compile fltk for X11. (The latter makes no sense under 10.5.)
In these cases, this bug was not observed.
14:40 Jan 14, 2008
|Could you please send some sample code. fl_draw_pixmap is used to draw Fl_Pixmaps which obviously works. Having sample source would make it a lot easier to find this bug. Thanks. ||
04:08 Jan 15, 2008
|>>> Briefly: I have attached a simple tetris game, in which fl_draw_pixmap is used and does not work. Alternatively, one can use Fl_Pixmap, and it works. |
>>> Software: fltk-1.1.x-r6020. You should configure it with --enable-quartz. If QuickDraw is used, everything fl_draw_pixmap works properly.
>>> OS: MacOS X 10.5.1.
>>> Why tetris: I have written a simple program that merely draws an xpm-image (taken from that tetris) in the main window. And it works fine even in Quartz! But I checked in the tetris whether fl_draw_pixmap gets the right xpm. It does. Furthermore, the tetris works properly if you compile fltk for Quickdraw.
>>> How to compile the tetris: I do not install fltk globally. Instead, I specify a local path in --prefix when configuring fltk. Then configure the tetris (using its 'configure') with the same path in --prefix. Then make it. Alternatively, you may use XCode. Then you need to change the paths of the fltk libraries: In the project window, go into "External Frameworks...", click every library with the right mouse button, choose "Get Info" and set your path. Both the methods (using configure+make and using XCode) should work and produce the same result. The only difference is that XCode creates a MacOSX-.app-Application whereas configure+make creates merely a Unix-executable (calles fltetris).
>>> How you switch between fl_draw_pixmap and Fl_Pixmap: Comment and uncomment lines 326-330 in fltetglass.cc. This is the only place in this version of the programm where fl_draw_pixmap is kept. But if you want, I can send you the previous version, where only fl_draw_pixmap is used.
>>> What you should look at: Start the program and launch the game by pressing the left button in the window. If you use Fl_Pixmap (not the current setting!), you will see a falling shape, and the glass will be filled with the squares. If you use fl_draw_pixmap, you see nothing except of the black background.
>>> fl_draw_pixmap vs. Fl_Pixmap: I looked through the fltk source code, Fl_Pixmap does not use fl_draw_pixmap. You are right, Fl_Pixmap uses fl_draw_pixmap (line 96 in Fl_Pixmap.cxx) but not directly for the screen. (Cf. line 149 in this file.) Can this be the matter? This tetris is an educational program, and use of fl_draw_pixmap for the direct screen output is a bit better for this purpose.
04:11 Jan 15, 2008
|Excuse me: In the last paragraph of my previous text, one "not" should be deleted: Fl_Pixmap does use fl_draw_pixmap. (Or, better, the sentence should be removed.) ||
08:19 Feb 14, 2008
|Confirmed on OSX 10.4.x. |
The issue lies in fl_draw_pixmap's usage of q_begin_image, applying origin translation incorrectly. This works for Fl_Pixmap due to the current matrix, which allows the image to be placed at +0+0 (resulting in a no-op).
- fl_draw_pixmap_text.zip: reduced test case based on posted code
- fl_draw_pixmap.patch: fix against trunk
10:21 Feb 14, 2008
|Fixed in Subversion repository. |
Thanks to wavexx's patch. If this bug is fixed for good (and I am pretty sure it will be), we have the very first bounty winner ;-)
[ Return to Bugs & Features ]