OSDev.org

alexfru wrote:How about you make it portable and profile in your regular OS with regular tools?
I'd actually suggest that most of code should be tested and debugged this way until your own OS can do it too.

mrjbom wrote:I noticed that when trying to draw a few lines of text, it is drawn very slowly. And this is present on all emulators, as well as on a real computer.
I also noticed that memory functions are called more than 7000 times, is this normal for the library?
I can't quite figure out if I need to look for problems in the memory manager or somewhere else.
Thanks.

if (glyphcache[idx] == NULL) {
    glyph = glyphcache[idx] = ssfn_render(&ctx, idx);
} else {
    glyph = glyphcache[idx];
}

bzt wrote:

alexfru wrote:How about you make it portable and profile in your regular OS with regular tools?
I'd actually suggest that most of code should be tested and debugged this way until your own OS can do it too.

A big plus on this! SSFN was made portable (relies on a pixel buffer and libc only) and there are several tests for this very reason. I ran those tests through valgrind, strace etc. on a Linux box, I suggest you to do the same with your code.

mrjbom wrote:I noticed that when trying to draw a few lines of text, it is drawn very slowly. And this is present on all emulators, as well as on a real computer.
I also noticed that memory functions are called more than 7000 times, is this normal for the library?
I can't quite figure out if I need to look for problems in the memory manager or somewhere else.
Thanks.

Yes. I have tried to minimize (re)allocation of memory, but there are many arrays to be kept track of when rasterising vector images. Outlines, even-odd pairs, one array per raster line, coloumns for counting pixels to detect hinting grid etc. For this reason you should cache the returned glyph and reuse whenever you can.

If you're using the same style and size for the font, you only need to render each glyph once. You should clear the glyph cache when you call ssfn_select to change the typeface, otherwise reuse them as much as possible. The API is designed in a way to make this easy: the returned glyph is a single byte array without pointers, contains only bitmap or alpha channel (without the actual foreground color), and kerning is implemented in a separate function, independently to the rasterizer etc.

For example, you could have an array of pointers to the glyphs, indexed by the UNICODE code point.

Code: Select all

if (glyphcache[idx] == NULL) {
    glyph = glyphcache[idx] = ssfn_render(&ctx, idx);
} else {
    glyph = glyphcache[idx];
}

Of course this is the simplest method. With 16 bit code points on 32 bit arch, this would require 256k additional memory. If that's too much, or if you want to handle all the more than one million code points, then you can implement a b-tree or a hash bucket list, etc. to look up the cached glyphs.

Another solution would be to use a font with bitmap glyphs and render that with ssfn_putc. That simple renderer was designed to be called many many times repeatedly, and it does not allocate any extra memory at all. The price for speed is that it cannot scale glyphs.

Cheers,
bzt

mrjbom wrote: Tell me, how can I improve the rendering quality?
For example, I draw text size 24 on a screen size 1280 * 1024, but to get the text of normal quality, you have to draw large characters (from 32), and this takes up a lot of space on the screen.

alexfru wrote:

mrjbom wrote: Tell me, how can I improve the rendering quality?
For example, I draw text size 24 on a screen size 1280 * 1024, but to get the text of normal quality, you have to draw large characters (from 32), and this takes up a lot of space on the screen.

AFAIR, with TrueType and similar vector fonts, it's very tricky to render characters of small size that look reasonably good, not just unambiguous. Also, some of the methods for that have been patented.
The simplest is to have separate small raster fonts for each size.

mrjbom wrote:Tell me, how can I improve the rendering quality?

bzt wrote:

mrjbom wrote:Tell me, how can I improve the rendering quality?

One thing that would considerably improve quality is to render to alpha channel. That allows anti-aliasing, which results in better looking glyphs.

mrjbom wrote:But it still doesn't look as good as in other systems. How can I make the text even better? Can I replace the font or something?

BenLunt wrote:Notice that there are other colored pixels around the black pixels. I don't remember what this is called

BenLunt wrote:

mrjbom wrote:But it still doesn't look as good as in other systems. How can I make the text even better? Can I replace the font or something?

Are you drawing in white on black background only?

Here is a very good example of how to make your fonts look better:

Go to https://fonts.google.com/specimen/Space ... ype=custom and zoom in.
(The best way to zoom in is to grab a screen shot and then zoom in on the screen shot.)

Here is a quick zoom of part of that screen:


Notice that there are other colored pixels around the black pixels. I don't remember what this is called, @bzt should be able to tell you, but this is why the fonts look better on these kind of systems.

A quick research should remind me what this is called, dithering, or something like that, but don't have the time to go look.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

mrjbom wrote:I have successfully used this modality, it has improved the quality of the text, but it still lags far behind those used in linux. I hope that bzt will tell me how I can make the text even more beautiful.

bzt wrote:

mrjbom wrote:I have successfully used this modality, it has improved the quality of the text, but it still lags far behind those used in linux. I hope that bzt will tell me how I can make the text even more beautiful.

I'm afraid you'll have to port freetype2 that Linux uses or you'll have to wait for SSFN 2.0.

Please note that freetype2 is huge (1M in size), and contains lots of complicated and dependency-heavy solutions (requires libm, libpng, libpthread, libgraphite, libbz2, libpcre etc. etc. etc). You'll have to have floating-point support in your kernel and port all of these library dependencies as well if you want to use freetype2.

SSFN on the other hand is targeted at embedded systems and therefore approx. 20k in size, uses integer-arithmetic only and has one single libc dependency. Obviously for these restrictions it must have a much much simpler algorithm than freetype2. But I'm not satisfied with this, so right now I'm experimenting with better looking rasterization methods without significantly increasing the complexity and the memory requirement. Hopefully there'll be a new version available soon which you can try.

Cheers,
bzt