nanogui: Thread: freetype2 now works

Hello -

I'm using the latest Microwindows/Nano-X from CVS, and have found
several problems with the "FreeType 2" support (engine/font_freetype2.c):

- Starting with FT version 2.1.8, the "ImageTypeRec" structure
   was changed.  Because of this, "font_freetype2.c" won't compile
   when "HAVE_FREETYPE_2_CACHE" is set to "1"

- Setting "HAVE_FREETYPE_2_CACHE" to "0" causes compile errors
   in "font_freetype2.c" (regardless of FreeType version)

- Starting with FT version 2.1.5, the "FAST" code in
   "freetype2_drawtext()" doesn't work (nothing is displayed).
   This "FAST" code is only used when the font's rotation angle
   is "0" (non-rotated).  Using the "SLOW" version always works
   (even if angle is "0").

- The "FAST" code in "freetype2_drawtext()" *does* work in
   FT version 2.1.4 and earlier, but only when MWTF_BASELINE
   is used.  For MWTF_TOP and MWTF_BOTTOM, the code was
   adjusting the "y" position in the wrong direction (adding
   a "y" offset instead of subtracting).

- "freetype2_setfontrotation()" was computing the wrong
   transformation matrix for non-zero angles (it was +90 degrees
   off, as compared to the code in "engine/font_freetype.c" (FT 1)).


I've modified "engine/font_freetype2.c" to 'fix' all of these
problems.  Some of the 'fixes' aren't really fixing the problem -
they just avoid them.  For example, if using FT version 2.1.5
or higher, I disable the "FAST" version of "freetype2_drawtext()".
Also, if using FT version 2.1.8 or higher, I force
"HAVE_FREETYPE_2_CACHE" to be "0" (which now works, because I've
fixed the compile errors that used to occur in this case).

With my changes, the "ftdemo" app using FreeType 2 now operates
the same as when using "FreeType 1" (1.3.1) (text alignment,
rotation angles are the same).  I've tested this with "FreeType 2"
versions 2.1.3, 2.1.5, 2.1.7, 2.1.8, and 2.1.10.

(It shouldn't make a difference, but my build environment is
"Fedora Core 4" (x86))



I've attached a new version of "engine/font_freetype2.c", as well
as a "diff" output (comparing to CVS version as of
today: July 7, 2005).


Comment blocks in the code describe the version-specific stuff
I'm doing (as I mentioned above).

To fix the compile errors (when "HAVE_FREETYPE_2_CACHE" is "0"),
I added 2 arguments to "freetype2_createfont_internal()" (the pointer
to the bitmap and the bitmap size).  These args are only used when
the 'filename' arg is NULL.

In "freetype2_setfontrotation()", I swapped the use of "sincosvec.x/.y"
to get the same results as the FreeType 1 version.

In "freetype2_drawtext()", I changed "ay += (pos.y >> 6)" to
"ay -= (pos.y >> 6)".  This fixes the "FAST" draw code to work
with MWTF_TOP/MWTF_BOTTOM alignments.


Let me know if you find any problems.

- Paul

Paul Bartholomew wrote:
> Hello -
> 
> I'm using the latest Microwindows/Nano-X from CVS, and have found
> several problems with the "FreeType 2" support (engine/font_freetype2.c):
> 
> ...
> 
> I've modified "engine/font_freetype2.c" to 'fix' all of these
> problems.  Some of the 'fixes' aren't really fixing the problem -
> they just avoid them.  For example, if using FT version 2.1.5
> or higher, I disable the "FAST" version of "freetype2_drawtext()".
> Also, if using FT version 2.1.8 or higher, I force
> "HAVE_FREETYPE_2_CACHE" to be "0" (which now works, because I've
> fixed the compile errors that used to occur in this case).

Has someone tested this by now? Is it already in CVS?

--
Steven

> > I've modified "engine/font_freetype2.c" to 'fix' all of these
> > problems.  Some of the 'fixes' aren't really fixing the problem -
> > they just avoid them.  For example, if using FT version 2.1.5
> > or higher, I disable the "FAST" version of "freetype2_drawtext()".
> > Also, if using FT version 2.1.8 or higher, I force
> > "HAVE_FREETYPE_2_CACHE" to be "0" (which now works, because I've
> > fixed the compile errors that used to occur in this case).
> 
> Has someone tested this by now? Is it already in CVS?

I don't have this patch, I'd like to see one against CVS.  Note
that the cache issue is different than the reason I disabled cache
support: the CVS version is from Gabrielle, it compiles
but doesn't run in all cases.  The non-cache version works great.

Regards,

Greg

>I don't have this patch, I'd like to see one against CVS.  Note
>that the cache issue is different than the reason I disabled cache
>support: the CVS version is from Gabrielle, it compiles
>but doesn't run in all cases.  The non-cache version works great.

Hmmm.  If I remember correctly (it's been a while), I sent the changes 
either to you or to the list when I announced the changes.

If nobody has the changes, I can re-send.  I haven't been working on nanogui 
stuff for quite a while now, so my mods may not apply to 'current' CVS code.

Let me know if I should re-submit the mods.

- Paul B.

Greg Haerr wrote:
>>>I've modified "engine/font_freetype2.c" to 'fix' all of these
>>>problems.  Some of the 'fixes' aren't really fixing the problem -
>>>they just avoid them.  For example, if using FT version 2.1.5
>>>or higher, I disable the "FAST" version of "freetype2_drawtext()".
>>>Also, if using FT version 2.1.8 or higher, I force
>>>"HAVE_FREETYPE_2_CACHE" to be "0" (which now works, because I've
>>>fixed the compile errors that used to occur in this case).
>>
>>Has someone tested this by now? Is it already in CVS?
> 
> 
> I don't have this patch, I'd like to see one against CVS.  Note
> that the cache issue is different than the reason I disabled cache
> support: the CVS version is from Gabrielle, it compiles
> but doesn't run in all cases.  The non-cache version works great.

Could you please shortly explain what exactly "caching" means w.r.t.
freetype?

IIUC then when using a freetypefont for the first time in an application
it is loaded from the *.ttf file and all characters are rendered into
some memory. Then these bitmaps are copied when needed.
This takes quite some time on my little embedded system.

So where exactly would this caching help?

--
Steven

> Hmmm.  If I remember correctly (it's been a while), I sent the changes
> either to you or to the list when I announced the changes.
>
> If nobody has the changes, I can re-send.  I haven't been working on
nanogui
> stuff for quite a while now, so my mods may not apply to 'current' CVS
code.

Paul -
    I've received your mods for the changes to the PCF font
engine, but not for Freetype 2.  The PCF changes have been
applied to CVS some time ago.

Please send your freetype 2 patch to the list, I'll worry
about applying it to CVS.

Thanks!

Regards,

Greg

> IIUC then when using a freetypefont for the first time in an application
> it is loaded from the *.ttf file and all characters are rendered into
> some memory. Then these bitmaps are copied when needed.
> This takes quite some time on my little embedded system.
> 
> So where exactly would this caching help?

I don't have the code in front of me, but generally the external
caching that nano-X developers have written takes the freetype
output bitmap format, which isn't in nano-X bitmap format, and
caches it in nano-X bitmap format for a given size and cache
range of characters.  In this way, character output is as fast
as internal font display, which are always stored in nano-X
bitmap format.

Regards,

Greg

Greg Haerr wrote:
>>IIUC then when using a freetypefont for the first time in an application
>>it is loaded from the *.ttf file and all characters are rendered into
>>some memory. Then these bitmaps are copied when needed.
>>This takes quite some time on my little embedded system.
>>
>>So where exactly would this caching help?
> 
> 
> I don't have the code in front of me, but generally the external
> caching that nano-X developers have written takes the freetype
> output bitmap format, which isn't in nano-X bitmap format, and
> caches it in nano-X bitmap format for a given size and cache
> range of characters.  In this way, character output is as fast
> as internal font display, which are always stored in nano-X
> bitmap format.

And these nano-X bitmaps are stored on a non-volatile memory (as a hdd)
so that will be used the next time the system starts? Or just in RAM so
they have to be rebuilt every time the system (and nano-X) is started?

Thanks,

Steven

: And these nano-X bitmaps are stored on a non-volatile memory (as a hdd)
: so that will be used the next time the system starts? Or just in RAM so
: they have to be rebuilt every time the system (and nano-X) is started?

No, no.  Think of the caching as the middle layer in the layered
API between the nano-X code calling the freetype library code.
The extra layer caches some number of bitmaps (usually LRU
based, sometimes character index based) in memory.  If not
found, then freetype is called [again] for the bitmap.  The
cache is only built based on calls from the the application
code.

Regards,

Greg