[XForms] Request for comments

[Jens Thoms Toerring]

Hi everybody,

   this is not an announcement of a new pre-release;-) I just wanted
to let you know that I'm still around, but wasn't very active on
developing XForms in the last few months due to too much other work
- and also being a bit frustrated:-(

   This frustration came from realizing that there's a major snag
with the new stuff about XFT fonts: the around the drawing of ob-
ject labels. The problem stems from the anti-aliasing of the XFT
fonts.

   To see the problem in action just run the 'buttonall' demo pro-
gram with current development version and click a few times on the
check-buttons and/or round-buttons. You'll notices that their labels
become fatter and fatter each time! The simple, and after a bit of
head-scratching, obvious explanation is that with anti-aliasing the
background is used to calculate how the bits at the edges of the
characters are drawn. And the redraw of the labels consists of just
redrawing the text itself, not the background. So, each time round
the background at the edges changes, as it had been modified due to
the anti-aliasing in the previous redraw. And if a label gets re-
drawn often enough, the part where anti-aliasing is done becomes
blacker and blacker, making the characters look "fatter".

   All this was, of course, no problem without anti-aliasing since
there the character simply got drawn without any influence of the
background. Except for the pixels of the character the label was
transparent. But with anti-aliasing there are now regions that
are party opaque.

The question is, of course, how to deal with that. And the major
problem is that the library has no idea at all what the background
of a label is (it didn't need to know before). So, to get it right
in all kinds of situations, one would have to redraw the whole form
each time a label must be redrawn. But that's something happening
rather often, and thus a lot of programs could become extremely slow!

   I've thought about this quite a bit trying to find a solution that
works properly (at least in most cases), but doesn't slow down things
too much - and doesn't require only a hopefully minimum amount of
changes to existing programs. The only practical way I've come up
with goes like this:

   Since we now need to draw a background with labels there's no way
around adding a new property for this to the object structure and,
of course, a function to manipulate it. It would be set to a default
color at object creation, where spending a bit of time trying to
figure out what's teh color of another object the label is going to
be drawn over (for "outside" labels this will mostly be the forms
background, or, if the object is e.g. in a box, the background
color of that box). With that in many cases things will look just
like they did before.

   One could also try to track color changes of objects that are below
labels  - such color changes probably aren't something that happens
very often (unless you've got e.g. a button with another object
with a label on top of it...), so that probably wouldn't slow things
down too much in most cases.

   So, my proposal is the following:

    a) Add a new property, the label background color and set it
       to the most likely color when the object is created.
    b) Have a function to change that background color (which then
       is always used) - and, if called with FL_NO_COLOR, revert
       back to the most likely color selection at that moment
       (i.e. the current color of the top-most object under the
       label).
    c) On color changes of objects check if there's an object with
       a label on top of it that has a no user-defined background
       color and adjust that background color as necessary (unfor-
       tunately, this probably must be done in an object-type
       specific fashion since there are s number of irregularities).

   But in situations where you have a label that overlaps several
objects (which actually never looked really nice;-) there's going
to be trouble - and there's no good solution for that I can see.

   I can't promise that this scheme will work with all existing pro-
grams, some may need some adjustments. So I'd like to ask you to
also think about a bit and tell me if you can come up with some bet-
ter ideas! And I'm well aware that my explanantion of the problem
could be a bit confused, so don't hestitate to ask for a clearer
explanation.
                         Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de