DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2659 Version: 1.4-feature 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 ? Link: http://www.fltk.org/str.php?L2659 Version: 1.4-feature _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
