nanogui: Thread: Font-drawing speed

Hi,
I'm using Nano-X (V. 0.89, framebuffer support enabled) on a PPC 
embedded Platform (~ 50 BogoMIPS) with large (14-54) freetype fonts. It 
is working fine, but - compared with the build in fonts - the drawing is 
very slow.

Is there another way to use large fonts? I didn't find a discription on 
howto add more build-in fonts to nano-X. If doing so, will this speed up 
the drawing?
I tried using pcf-fonts, but they can't be loaded (the pcf_read_toc() 
seems to read wrong size information and then the calloc fails - did I 
use the wrong fonts?). I used 75dpi and 100dpi X11 fonts for testing 
(courB24-ISO8859-1.pcf). Are these fonts correct for using with nano-X? 
Will they be drawed faster than the freetype fonts?

Regards,
       Klaus

Hi,

> I'm using Nano-X (V. 0.89, framebuffer support enabled) on a PPC
> embedded Platform (~ 50 BogoMIPS) with large (14-54) freetype fonts. It
> is working fine, but - compared with the build in fonts - the drawing is
> very slow.

Have you enabled glyph caching?  Copying src/engine/font_freetype.cache.c over font_freetype.c and recompiling should enable it, but I haven't tried this.  (I use a custom font driver).

Kind regards,

Jon Foster
--

> I tried using pcf-fonts, but they can't be loaded (the pcf_read_toc() 
> seems to read wrong size information and then the calloc fails - did I 
> use the wrong fonts?). I used 75dpi and 100dpi X11 fonts for testing 
> (courB24-ISO8859-1.pcf). Are these fonts correct for using with nano-X? 

The PCF reader should be bug-free, with the exception that it
doesn't work on big-endian systems, since it doesn't yet try
to byte-swap.  (You must use v0.89, prior versions were buggy).
If you're running 0.89 and little-endian, please send me the .pcf
font and I'll take a look at it.



> Will they be drawed faster than the freetype fonts?

Definitely, they're converted to the same internal bitmap format
as the built-in fonts.

Regards,

Greg

>
>
>Have you enabled glyph caching?  Copying src/engine/font_freetype.cache.c over font_freetype.c and recompiling should enable it, but I haven't tried this.  (I use a custom font driver).
>  
>
I enabled it and the drawing is faster - but still rather slow. I think 
I'll try using the pcf fonts...
Thank's for this information.

Regards
      Klaus

Greg Haerr wrote:

>The PCF reader should be bug-free, with the exception that it
>doesn't work on big-endian systems, since it doesn't yet try
>to byte-swap.
>
That's it! (on an x86-pc it is working) I have a big-endian system 
(PPC), so which parts have to be fixed?

>Definitely, they're converted to the same internal bitmap format
>as the built-in fonts.
>  
>
Is it difficult to add more build-in fonts? I only need two larger 
fonts. Is there a documentation for this?

Thanks & regards,

Klaus

Greg said:

>> since it doesn't yet try to byte-swap.

Thats actually incorrect, because we end up byte swapping everything
while its reading in the bitmaps.

The PCF format does indicate the format of the bitmaps.  Attached is a
patch that attempts to make some use of that format to decided if we
should byte swap or not.

 I believe that this is the only place where we have to worry about
endianism, but since I don't have any place to test this, don't take my
word for it (please!).  I have tested on x86, and it seems to
compile and run correctly.

Comments are welcome,
Jordan

> Is it difficult to add more build-in fonts? I only need two larger 
> fonts. Is there a documentation for this?

Look at drivers/genfont.c and src/fonts/Makefile

Regards,

Greg

Jordan Crouse wrote:

>I believe that this is the only place where we have to worry about
>endianism, but since I don't have any place to test this, don't take my
>word for it (please!).  I have tested on x86, and it seems to
>compile and run correctly.
>  
>
Thank you for the patch!  It compiles, but it does not the whole trick. 
Nevertheless - it helps me to make things going.
In pcf_createfont() the FREAD function reads a couple of bytes, which 
are interpreted as int or long. At this point the endianess gets important.
I  wrote a patch which swaps the bytes just behind the FREAD calls (for 
big-endian machines). Now, I'm able to read pcf fonts on a big-endian 
system (it still works on littlle-endians too)!
I tested it without compression, but I think this makes no difference 
for endianess, do you agree?

I'm looking for larger pcf-fonts (I only have a 24 point font). Where 
can I get larger pcf fonts?

@ Greg: Are you interested in this patch? Shall I send it to you 
(private or mailingl-list?)?

Thank you all for helping me.


Regards

Klaus

On Tue, 28 Jan 2003 17:15:14 +0100
Klaus Fürth ####@####.#### wrote:

> @ Greg: Are you interested in this patch? Shall I send it to you 
> (private or mailingl-list?)?

Klaus -

If you could, can you make a patch against the the released version of
microwin-0.89 (including my patch, and your changes) and send it to the
list?   Thanks for looking into this.

Regards,

Jordan

Hi Jordan!
Hi Greg!

I got two different answers about the patch. Because it is rather small, 
I hope it's ok sending it to the list. I made the patch against the 
released version of mircowin-0.89, including Jordan's patch.

There are two places in the code I could not test:
1. Function pcf_readmetrics(): if (format == PCF_DEFAULT_FORMAT)...  I 
did some patches to it, but I have no font to test with. I think this 
should work ;-) If you can send me a font, I'll test it.
2. Function pcf_createfont(): I could not test Jordan's patch, because 
my system doesn't reverse the bits. (I think "big-endian" means, that 
the bytes are swapped, am I right? Are there some systems with reversed 
bits?)

I hope the patch will work as expected (it is only tested on X86 with 
X11 (little endian) and on a PPC embedded system with framebuffer (big 
endian)).

Does anyone know a source for large pcf fonts? Where can I find one?

Regards

Klaus