Am 17.03.2013 22:17, Chris Russ wrote:

>>> 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...
> Here's the link to the documentation that says it:
> Search on the page for the word "transparency"...

Thanks for the link. I'll try to improve this later.

> The documentation also strongly discourages people from using the ->draw() 
> method of widgets.

Yes, and it is important not to call draw() from any callback,
be it a widget's callback or a timer update or any other.

However, if you are already within a draw() method of one widget,
then it is allowed and useful to use other widgets' draw() methods,
e.g. for a group or a complicated widget layout (draw the background
image, then a graph, then another Fl_Box with a bargraph on top of
it, similar to your case).

> My problem is solved, thank you.  But the docs are, shall we say, confusing.

Yep, you're right. The entire chapter needs some improvements
and probably some examples. I'll see what I can do when I can
find the time. Thanks for the heads-up.


fltk mailing list

Reply via email to