FreeType project ported to RDOS kernel device driver

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Post Reply
rdos
Member
Member
Posts: 3286
Joined: Wed Oct 01, 2008 1:55 pm

FreeType project ported to RDOS kernel device driver

Post by rdos »

I have the basics of FreeType working now in kernel mode. This is my second C based device-driver (ACPI was the first one), which seems to work well in 32-bit compact memory model. The only problem with FreeType is that the designers have never heard of multitasking, so there is a need to rewrite the upper layers with proper locking. But the TrueType renderer at least work with standard Windows font files (like Arial), and have a gray-scale anti-aliasing algorithm that uses 256 levels!

The goal is to fully support UTF-8 in the GUI, so I don't need special font-files.
User avatar
bubach
Member
Member
Posts: 1223
Joined: Sat Oct 23, 2004 11:00 pm
Location: Sweden
Contact:

Re: FreeType project ported to RDOS kernel device driver

Post by bubach »

Do you have some cool screenshots or maybe an img file that we could comment on?
"Simplicity is the ultimate sophistication."
http://bos.asmhackers.net/ - GitHub
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: FreeType project ported to RDOS kernel device driver

Post by Owen »

From the documentation...
A handle to a FreeType library instance. Each ‘library’ is completely independent from the others; it is the ‘root’ of a set of objects like fonts, faces, sizes, etc.

It also embeds a memory manager (see FT_Memory), as well as a scan-line converter object (see FT_Raster).

For multi-threading applications each thread should have its own FT_Library object.
rdos
Member
Member
Posts: 3286
Joined: Wed Oct 01, 2008 1:55 pm

Re: FreeType project ported to RDOS kernel device driver

Post by rdos »

I now have a functional device-driver. It can either be compiled with super-secure segmentation where every FreeType object gets it own selector and precise limit, and every glyph entry gets it own selector as well, or with a less secure version that uses the kernel flat selector. During the debug phase I use segmentation, while in the release phase I'll use a flat selector in order not to exhaust GDT entries. Because of this design, I now know there are no memory overwrites in the code. The new fonts works with our terminal, and with a few test apps I have. At least for 32-bit VBE. I need to update 24, 16 and 1 bit interfaces as well.
Post Reply