On 29.04.2011 10:41, Evan Laforge wrote: > Wouldn't it just be "add transparency to fl_draw_image() on all > platforms"? I'm not the one who wants to draw transparent images, > just rectangles, so I haven't really followed that bug, and I've never > used fl_draw_image(). As long as Fl_RGB_Image::draw continues to > support alpha then I'm happy, but then again the only reason I'm using > that is a hack to get around the lack of transparency for fl_rectf :) > > I would have thought fl_draw_image was the primitive that Fl_RGB_Image > just called, but looking at the source, apparently not so.
Yep, I would have thought that too, but unfortunately it is not. One reason might be caused by adding transparency later, but I think that the main difference is image (bitmap) caching that is only possible if you have an "object" like Fl_(RGB_)Image. fl_draw_image() simply can't do that :-(, and thus we need two different approaches, since IMHO we wouldn't want to lose the performance enhancements of caching (partic- ularly when using X11). I'd like to take another look at it at the next weekend, and I hope that I will have a few hours available. > On the subject of fl_rectf transparency, would it be reasonable to > have them pay attention to an alpha byte in Fl_Color? I imagine OS X > support would be pretty easy since it supports alpha stuff natively, > and I guess modern windowses too. Not sure about X. There's no room for an alpha channel in Fl_Color, since the 4th byte is occupied by the colormap index, at least if R, G, and B are zero. I don't think that extending Fl_Color's definition to use RGBA would work in a compatible way. However, drawing a rectangle with alpha channel would be pretty simple, if fl_draw_image() would support transparency - you would only have to provide one pixel line in a buffer callback function (setting ld() to 0 wouldn't work, unfort- unately, because of the default meaning 'w*h' then). Other shapes might be more complicated, obviously. > On Sat, Apr 23, 2011 at 1:42 PM, Manolo Gouy<[email protected]> > wrote: >> Agreed. Could you, please, post this RFE yourself specifying >> what image format support would be necessary beyond RGBA ? >> I would then close STR #2583. Evan and Manolo, I'll take another stab at it at the weekend, and if you (Manolo) don't mind, I'll add the new STR then, and close the old one. Okay? Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
