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
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
