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

[Infinality]

> > 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
> review.
>
> 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.

Thanks,
Erik