On 16.03.2013 03:21, Chris Russ wrote: > I've been working on a widget that can show images zoomed in and out at > arbitrary percentages, and that part works. Now, in the middle of my > ::draw() function I want to overlay some RGBA PNG images -- these have > transparency where I'd like the underlying image to show up. > > I can make the images show up in the right places, but the alpha channel is > being completely ignored in this little snippet: > > void *baseaddr = (void *)(head->image_->data()[0]); > int imagew = head->image_->w(); > int imageh = head->image_->h(); > int imaged = head->image_->d(); > fl_draw_image((const uchar *)baseaddr, x, y, imagew, imageh, imaged); > > head->image_ in this case was an Fl_PNG_Image that should have 4 channels. > It has been cast into an Fl_RGB_Image, which should be a compatible type. > > But alpha blending isn't happening. I'm getting white where there should be > transparency to the pixels previously drawn in the buffer. Instead, I should > be getting a blend using the variable opacity in the A channel.
As Ian and Greg pointed out already, alpha blending works with FLTK 1.3 (and even with 1.1), but there are some restrictions. Unfortunately you chose to use fl_draw_image(), but this function does support alpha blending only on Mac OS X with FLTK 1.3 (this is not intended, but currently that's how it is :-( ). In FLTK 1.1 and 1.3 you can use the image drawing methods instead, and *these functions* support alpha blending. So you can use the png image directly, as Greg did in his example (see his posting). You can also take a look at the source file test/unittest_images.cxx to see how it is done there. Note that this is a *unittest* code and not an example for good FLTK programming. However, the comments show what I stated above, and the code shows how you can use arbitrary image data, convert it to a RGB image, and use the image drawing method to draw it (selected by preprocessor macro IMG) vs. using fl_draw_image(), which would work only on OS X). As I said before, that's not the recommended way for your problem, since you could use the image drawing method with the png image. > Upon further investigation, the documentation says that the only way to get > transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a GIF > file), and that is definitely NOT RGB. Even so, would that work where this > fails, albeit without the kinds of shadows I'm trying to cast in the PNGs? That's not up-to-date anymore, could you give a pointer where you read it exactly? This documentation should better be updated, but as I wrote before, the current state of image drawing was not intended and should be more consistent across platforms. However, it's not as easy to do it as it might seem, and somebody has to do it. Patches always welcome... > The documentation also points out a function called fl_read_image() where I > could copy out the area underneath where the PNG is destined to be drawn. > Therefore I could do the alpha blend myself and then do a regular > fl_draw_image() to put the blended image in place. Is this the only way it > will work? No, see above. This is something you could do if the background changed outside of your control, but I wouldn't do it in your case. Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
