commit - Major beos changes

Daniel Joseph Berlin (
Sun, 7 Nov 1999 00:19:07 -0500

The past few days, i've been making major changes in the BeOS port.
Among other things, flickering is gone (even in no-optimization debug
builds), the zoom dialog is working, the font dialog is almost working,
timers have been completely redone, accelerators are correct and work, and
many other things.

I also had to add some casts in places they were missing (but belong) in
various places, because the new GCC will give me errors on them rather
than just warnings.

As of my commit a few hours ago ago, the BeOS port should no longer have
on screen jitter due to float->int spacing problems (For those out of the
know, BeOS uses floats for font sizes/etc). This has been a *long*
standing problem, AFAIK, and AFAIK, it is now fixed.

For those interested as to how this is done, here goes.

Before, we would just cast the floats of char widths and whatnot to ints,
and lose majorly when things like highlighting >1 char selections with the
mouse (because it would try to clear the space in between characters, and
since it was wrong, cut off the front of characters), zooming, and even
changing font size, occurred.
The worst was really the highlighting of selections and zooming.

If you zoomed, whenever you selected/unselected/basically made the string
redraw, it would move to the left or right (jitter), and caused artifacts.

Now, it all works.
Well, after mulling this problem for the past 2 days, thinking of various
solutions (multiplying/dividing by 100 to gain more precision or making
UT_uint32 a real class that could take floats were the best solutions i
came up with).
Then, this morning, I realized it would be much easier to try to make
Be just draw the text where we told Abi it was, than try to make Abi
handle floats properly.
Sure enough, it can be done. In fact, it can be done with no
odd looking spacing, either.
So this is what is now done.

If you want gory details, look at gr_BeOSGraphics.cpp at measureString and

It's currently not the most optimal implementation in terms of speed, but
i'll deal with that later.

You can still make it cutoff in between major font size changes, but it
shouldn't reposition.
The cutoff happens because i haven't found a way to take into account the
last character in a drawn string's width (since we draw the character at
the previous character+previous character width), so at font change
points, we lose a very small amount of space.

This won't cause repositioning or jitter, however.
Unless someone has a pathological case i missed.


This archive was generated by hypermail 1.03b2.