[Top][All Lists]

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

Re: [ft-devel] Patch to fix the ttsubpix implementation

From: Infinality
Subject: Re: [ft-devel] Patch to fix the ttsubpix implementation
Date: Wed, 16 Jan 2013 22:38:51 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Was just looking at the source base today and found some rather sad
things added recently.

Here's a first patch to properly define all the sub-pixel handling
tables in ttsubpix.h to the appropriate location (in ttsubpix.c,
defined as constants).  This saves about 55 KB of private RAM per
process that loads the library on Linux. That's *pretty* bad.
Please people, be careful about your code.
Thanks, David!  I must admit that I've missed this.  Mea maxima culpa.

Note that the sub-pixel code is not activated by default.  There are
still serious problems with it (especially on the performance side) so
it is marked as experimental for good reasons.  BTW, Erik is
completely reworking it currently.

Not sure if "completely" is the correct adverb, but trying to make some performance improvements and implementation changes to better align with the whitepaper. :) Guys, I'm not a hardcore C coder, and don't know about private RAM allocation per-process, and how that's impacted by putting structs inside of .c files instead of .h files. Of course, I'm willing to understand why that's the case, I just don't necessarily know some of that stuff. So, likely all code that I write is going to have the potential of being implemented more efficiently by people with more experience in coding. I don't really want to burden you guys with "babying" me through the best way to implement code, but if you can nudge me in the right direction sometimes that would be helpful.

I'll hope to provide more cleanups later.
Please don't do that right now; it's probably wasted time.  As soon as
Erik has committed his new code, I'll drop you a note so that you do a

I've applied your patch.
Yes, I'm still working through this... I'm attempting to do automatic detection of FDEF signatures so that "compatibility_mode" doesn't have to be hard-coded for specific fonts. Ideally, most hard-coded stuff can be removed eventually.


reply via email to

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