from localhost (jalapeno [127.0.0.1])
	by example.com (Postfix) with ESMTP id 1C65916F1F
	for <zzz@localhost>; Wed,  9 Oct 2002 10:51:25 +0100 (IST)
from egwn.net (auth02.nl.egwn.net [193.172.5.4]) by
    dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g996IjK22331 for
    <zzz-rpm@example.com>; Wed, 9 Oct 2002 07:18:46 +0100
No, hits=-0.1 required=5.0
	tests=AWL,KNOWN_MAILING_LIST,RCVD_IN_MULTIHOP_DSBL,
	      RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,T_NONSENSE_FROM_40_50,
	      USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG
	version=2.50-cvs

Following further study, I've concluded:
1. It is easy to enable the bytecode interpreter.
2. This noticeably improves rendering of non-antialiased text.
3. This noticeably *harms* rendering of antialiased text.
Point #3 probably surprises the rest of you as much as it surprised me.
Ever since turning on the bytecode interpreter, I've been bugged by a
sense that the antialiased text in my GNOME2 applications just looked,
well, wrong somehow.  I finally took some comparison screen shots with
and without the interpreter, and that made the difference crystal clear.
Consider the two images attached below.  The first, "no-bytecodes.png",
shows some text rendered by a GNOME2 panel menu without the bytecode
interpreter.  Contrast this with the second, "bytecodes.png", taken with
the bytecode interpreter enabled.
When the bytecode interpreter is turned on, notice that several
rendering anomalies appear:
- Several letters are narrower, giving the whole run of text a more
compressed feel.  This is especially noticeable in "R" and "o".
- The left side of the "Q" is painted in too light a shade of grey,
causing it to drop out somewhat.  "C", not in this sample, has the
same problem.
- "Qu" are set right up against each other, with insufficient
whitespace between them.
- "M" is distinctly asymmetric.
- The enclosed loop of "a" looks muddy, as it is partially filled
with grey.  Contrast with "a" drawn without the bytecode
interpreter, which has a nice clear open loop.
Ick.  Perhaps this is why Red Hat turned the bytecode interpreter off.
It may improve non-antialiased rendering, but only at the expense of
making a mess of antialiased rendering.
This may come down to a matter of personal aesthetics, but for my part,
I'm going back to Red Hat's standard packages with the bytecode
interpreter turned *off*.