freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] FreeType patches to support amalgamation


From: Chris Morgan
Subject: Re: [ft-devel] FreeType patches to support amalgamation
Date: Tue, 21 Feb 2012 11:07:17 -0500

On Tue, Feb 21, 2012 at 11:01 AM, Vinnie <address@hidden> wrote:
>> From: Dmitry Timoshkov <address@hidden>
>
>> Sent: Tuesday, February 21, 2012 8:53 AM
>>
>>>  With an amalgamated version of FreeType I can add support for hinted
>>>  fonts to my open source offerings, while including the entire FreeType
>>>  distribution as a single source file instead of a large tree.
>>
>> How about providing a single precompiled library file for these people?
>
> That would only work for one particular build environment, and within that
> environment, only one target. For example, debug, or release. Or 32 bit versus
> 64 bit. If the resulting FreeType library were misused, the absence of sources
> would complicate debugging. One could simply include the full FreeType
> source tree but then we are back where we started. Keep in mind, I try to
> target most popular platforms (Windows, Mac OS, iOS, Android, GNU/Linux
> with X Windows) by using a cross platform library ("Juce").
>
> I'm sensing a lot of friction with producing an amalgamated distribution of
> FreeType. Perhaps this comment will sweeten the pot:
>
> From http://www.sqlite.org/amalgamation.html
> "In addition to making SQLite easier to incorporate into other
> projects,
> the amalgamation also makes it run faster. Many
> compilers are able to
> do additional optimizations on code when
> it is contained with in a single
> translation unit such as it
> is in the amalgamation. We have measured
> performance improvements
> of between 5 and 10% when we use the
> amalgamation to compile
> SQLite rather than individual source files.
> The downside of this
> is that the additional optimizations often take the
> form of
> function inlining which tends to make the size of the resulting
> binary image larger."
>

>From experience the amalgamated sqlite is a bit of a pain since the
project doesn't seem to support a non-amalgamated build and it was a
pain including the c headers into some c++ code. I've got a bit more
experience integrating legacy c projects with c++ now so maybe it
would be easier for me but I think I couldn't use the amalgamated
approach because there are lots of sqlite structs/types that aren't
c++ compliant.

In any case, modern compilers can do whole program optimization and
its only 5 or 10% performance improvement. You'd have to create a
benchmark and test the two types of builds with a modern compiler in
order to start to collect the data to make the same argument with
freetype.

Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]