[Top][All Lists]
[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
Re: [ft-devel] FreeType patches to support amalgamation, Werner LEMBERG, 2012/02/24
Re: [ft-devel] FreeType patches to support amalgamation, Vinnie, 2012/02/21
Re: [ft-devel] FreeType patches to support amalgamation, Alexei Podtelezhnikov, 2012/02/21
Re: [ft-devel] FreeType patches to support amalgamation, Vinnie, 2012/02/21