| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2659
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Image Support |
Summary: | support conversion from Fl_Pixmap to Fl_RGB_Image |
Version: | 1.3-feature |
Created By: | ossman |
Assigned To: | ossman |
Fix Version: | 1.3-current (SVN: v10192) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | ossman 09:20 Jun 08, 2011 |
| This can be convenient at some points as XPM is easily embedded in the source code, whilst Fl_RGB_Image is easier to do more advanced stuff with.
PS. Meant to set this as 1.4-feature, but that option is gone. | |
|
#2 | AlbrechtS 09:32 Jun 08, 2011 |
| Moved to 1.4-feature as requested. | |
|
#3 | astrand 05:35 Jun 19, 2012 |
| Updated patch for latest trunk. I think we should consider this patch for 1.3.x. It actually simplifies a lot of things, see diffstat:
FL/Fl_Image.H | 2 src/Fl_Image.cxx | 13 ++ src/fl_draw_pixmap.cxx | 307 ++++++++++++++----------------------------------- 3 files changed, 105 insertions(+), 217 deletions(-) | |
|
#4 | manolo 09:18 Jun 21, 2012 |
| With this patch, printing pixmaps to PostScript no longer works. Use the device demo program under X11 and click the "Print" button. | |
|
#5 | ossman 03:51 Jun 26, 2012 |
| The patch is actually fine, but it exposed a bug in the postscript code. This small patch fixes it:
diff -up ./src/ps_image.cxx.orig ./src/ps_image.cxx --- ./src/ps_image.cxx.orig 2012-06-26 12:50:10.746660116 +0200 +++ ./src/ps_image.cxx 2012-06-26 12:50:11.979638864 +0200 @@ -217,7 +217,7 @@ void Fl_PostScript_Graphics_Driver::draw uchar *curmask=mask; for (j=0; j<ih;j++){ - if (mask){ + if (mask && lang_level_>2){ for (k=0;k<my/ih;k++){ for (i=0; i<((mx+7)/8);i++){ | |
|
#6 | manolo 10:47 Jun 27, 2012 |
| With both patches, the device test program outputs a valid PostScript file but the transparent background of the pixmap doesn't appear transparently in the PostScript interpretation.
Fl_PostScript_Graphics_Driver, at present, expects the void Fl_PostScript_Graphics_Driver::draw_image(Fl_Draw_Image_Cb call, member function to be called to process pixmap correctly.
The patch would require, I believe, to re-organize also this section of Fl_PostScript_Graphics_Driver. | |
|
#7 | ossman 02:13 Jun 29, 2012 |
| This patch removes the duplicate code between the different draw_image(), but having one call the other. This makes sure you get the same features no matter which method you use. | |
|
#8 | manolo 02:46 Jul 01, 2012 |
| I believe the attached test pixmap file big2.xpm is not correctly displayed with the pixmap_browser test program under X11 when the patches are applied.
More generally, I'm unsure whether such an important change can be made in FLTK 1.3 because making sure there's no hidden problem proves difficult.
Also, the patch reveals an inconsistency of the FLTK API regarding Fl_Graphics_Driver subclasses: the virtual member function void draw(Fl_Pixmap *pxm, int X, int Y, int W, int H, int cx, int cy) does not in practice draw the pixmap, but returns to FLTK calling fl_draw_pixmap() which calls itself another Fl_Graphics_Driver virtual member function. Which virtual member function is not explicitly defined in the API of Fl_Graphics_Driver. It's void draw_image(Fl_Draw_Image_Cb cb, void *data, int X, ...) in the current FLTK source, whereas it's void draw_image(const uchar *buf, int X, ...) in the proposed patch. These virtual functions have to react in an undocumented way to the value of the fl_mask_bitmap global variable which is set only when drawing pixmaps.
User code may therefore be destroyed by the patch if it processes fl_mask_bitmap in draw_image(Fl_Draw_Image_Cb, ...) and not in draw_image(const uchar *, ...). This happens with my own Fl_PDF_Graphics_Driver custom subclass of Fl_Graphics_Driver.
Clearly, pixmap drawing is more messy than it ought to be, and the proposed patch does improve this mess a fair bit, without removing the API inconsistency.
What should we do ? | |
|
#9 | manolo 10:32 Jul 01, 2012 |
| The attached pixmap.patch gathers all patches considered here and fixes the issue that appeared with test file big2.xpm.
Should I commit that ? | |
|
#10 | astrand 05:56 Jan 16, 2013 |
| Yes, please apply. The pixmap_v2.patch has been adapted to FLTK 1.3.2. Hopefully applies to trunk as well. | |
|
#11 | ossman 06:29 Jun 12, 2014 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |