Freetype2 Modules

[ghost]

I will attempt to keep this short. However, do we really need to be building all of these modules?

For example the only modules required to build opl are as follows:

FONT_MODULES : truetype sfnt
RASTER_MODULES : smooth
AUX_MODULES :  gzip
BASE_EXTENSIONS : ftbitmap.c

When opl is build with only these freetype modules the size reduction is about 17%. The exact numbers are below.

All Modules
Unstripped Uncompressed: 3,273,139 bytes
Stripped: 2,275,516 bytes
Strpped Compressed: 1,067,801 bytes

Reduced Modules
Unstripped Uncompressed: 2,782,593 bytes (15% Reduction)
Stripped: 1,926,976 bytes (15.3% Reduction)
Strpped Compressed: 886,217 bytes (17% Reduction)

[sp193]

Do you know what to change? What modules are currently enabled?

I did the port of libfreetype 2.4.12, but then I just updated the files to the current version without reviewing whether the semantics of the old build files were suitable. The only reason why I moved up, was to fix some problems I had with libfreetype faulting with certain types of fonts I used with my software.

[ghost]

I'm currently unsure of the best approach to take. I think it may be best to allow the user to specify which modules to build either directly or by a specific project and have it default to something.

Currently it appears that all modules are enabled and being built.

Also I remember you mentioning that freetype can be slow without caching. While looking at the modules I noticed that there is a cache module enabled that may be worth taking a look at. I'm going off memory though so please don't hold me to it.

[sp193]

But... there would be no point of having FreeType as a library (which is supposed to be used across various projects). :( Usually, objects that contain no symbols that are used by other code of the project, will be ignored during linking. We're exploiting this in the design of our libkernel code, so that only the necessary functions will be picked by LD. So having more options enabled in projects like this one, should not result in much additional bloat. I don't understand how this became such a problem, of such a scale (it's not 10-20KB, looks like it's nearly 500KB).

If I wrote that Freetype might be slow without caching, that was an understatement. At least because the I/O subsystems on the PS2 are slow, not having caching resulted in the very sort of lag that the UIs of my 4 pieces of software were exhibiting! I don't know about the cache system you mentioned. Thanks for bringing it up. I might have wrote my software before the cache was added, so I implemented my own.

[AKuHAK]

For now maybe it will be useful to something like opl "config" inside freetype project. 500 kb is really big difference for such approach.

[ghost]

It may be that the linker needs to be looked at then. From building the example in freetype tutorial 1 where the library is only initialized, one can see that everything gets linked into the elf and exists even after running: ee-strip --strip-unneeded

[sp193]

According to the GNU Binutils manual, --strip-unneeded will "Remove all symbols that are not needed for relocation processing". It'll remove data like the names of functions, but the actual code is still there.

Do we know if FreeType has a recommended list of modules that should be built? Or is building all of them the typical approach? Is there even documentation for configuring this?

I was looking at modules.cfg. Did you edit this file to configure the modules that will be built? Since the default is to build all modules, maybe we should just reduce the number of modules.

I think 500KB isn't going to kill anyone though, since our games are so much larger anyway. But it's still annoying to know that the ELF has grown 500KB over seemingly nothing. This really shouldn't be our problem. There are many other PS2-related problems to fix!

[ghost]

modules.cfg was indeed the file I had edited. You're right it really shouldn't be our problem. I just happened to stumble across it and figure it was worth bringing up. It would be convenient if there was a way to select which objects to use from a library when linking instead of the whole archive. We could then use macro's or something to select a set of objects to use. It would also help with the issue of gsKit where if it is build using libpng, libjpeg, or libtiff and a program using gsKit doesn't link the library it causes an undefined reference error.

[sp193]

Since all of our current projects just use it to support TrueType fonts of sorts, we could probably even get away with the most minimal selection of modules as well...

But if we want to edit modules.cfg to have the fewest modules, we have to ask @AKuHAK how to edit this file now. I don't know how to work with this build system.

The dependency problem with gsKit is unrelated. It's caused by gsToolkit.c, within gsKit itself. That was taken care of.

[ghost]

While testing I simply commented out what I wanted to remove.

Also I believe ule uses .fnt format but I'm unsure if it is using freetype or not.

EDIT: The issue with ld not removing the unused portions of code may just have to do with the age of the toolset being used. There are somethings that just don't work the way they are supposed to. For example no matter how loud you scream at gcc inline void foo (const char) __attribute__((always_inline)); it simply will not care.

[sp193]

That is plausible. But also sad if true. :( If the toolchain's version is the problem, then there is nothing much that can be done. Since there's no newer version that is complete.

LaunchELF does not use FreeType.

The _alwaysinline attribute seems to be already supported by v3.2.3: https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Function-Attributes.html#Function%20Attributes