Re: font dialog error
[email protected] Thu, 04 Sep 2025 12:29:01 -0500
| Newsgroups | gmane.comp.lib.fox-toolkit.user |
|---|---|
| Message-ID | <[email protected]> |
On 2025-09-04 11:00, John Selverian wrote:
> v1.7.50
>
> It is a custom widget derived form the standard font dialog.
So, some background about the problem:
1) On Linux, we use Xft [XLFD still works, but looks really ugly].
Fonts
in Xft can be measured a character at a time, so we can avoid
overflowing.
Measuring character at a time was necessary because
XftTextExtentsUtf8() was
using a 16-bit short, which overflows too quickly.
2) Due to fixes in FXTextField, we no longer draw invisible text, just
visible
text. Buffer limits or client-server transfer limits less likely to
be a
problem. Of course this should also be faster.
3) On Windows, I've split text measurement and drawing into two
branches; the fixed-
buffer version, which lives on the stack, is used for short strings.
In the rare case we have a large string, we allocate variable size
buffer and
use it for the utf8->utf16 conversion, then free it immediately.
Alloc/free overhead can be a lot, so we prefer to do it only when
needed.
Either way, for drawing purposes, strings are transferred between your
FOX program
and the drawing system [X11 or GDI] and if you have a large string,
trouble MAY
still ensue. FOX widgets which may have very long strings [FXText and
FXTextField]
are now safe against this, since drawing has been limited to the part of
the text
that's visible, which by definition is much less than the whole screen.
Most other widgets won't have very long strings and should be OK.
I recommend custom widgets that deal with really long strings should be
looked at
and potentially updated to draw only the visible fragments; this would
avoid
these problems, and at the same time, significantly speed up drawing.
-- JVZ