Poor font rendering..
Jim Graham
james.graham at oracle.com
Thu Mar 6 16:54:22 PST 2014
If you look at the first "o", the version on top has a leading edge that
is only 2 pixels wide and the one below is a dark middle column flanked
by 2 lightly colored columns. It's as if the placement on the lower
text is trying harder to center its columns of sub-pixel samples to
ensure that there is at least one column that gets hit by the darkest
majority of the LCD sub-pixel weighted samples, but the one on top just
distributes them as they arrive. Spreading 6 samples, with the middle
samples being the darkest, evenly over 2 pixels has much less contrast
then distributing them with the darkest 3 samples in the middle on one
pixel and the remainder lower-coverage samples distributed on the pixels
to the left and right of the stem.
Felipe's recommendations for turning off sub-pixel shifting of the text
may impact this if, for instance, the rasterizer returned LCD samples
that were intended to start on an integer boundary so that all stems had
their darkest parts on a single pixel, but then our placement algorithm
decided to place the entire glyph on a 1/3 pixel alignment instead...
...jim
On 3/6/14 2:53 PM, Phil Race wrote:
> I am not sure what you are looking at but I see 255,255,255 pixels on
> all sides of
> the stems. The stems are touching 3 pixels. I'm talking about the ones
> to the sides of
> those 3 pixel wide stems.
>
> In any case I've used Windows 7 wordpad and Segoe UI 9pt (aka 12pixel) and
> can see identical rendering to your Outlook case.
>
> Wordpad (and so I infer Outlook) is using GDI which
> 1) is very likely a different rasteriser (FX is using the one from
> DirectWrite)
> 2) doesn't do sub-pixel positioning because its only got int APIs.
>
> So this seems to come down to DirectWrite vs GDI and personal
> preferences ...
>
> -phil.
>
> On 3/6/2014 1:57 PM, Scott Palmer wrote:
>> That's not true. There is a difference in the "white" space around
>> the letters. The "white" pixel before the stem of the L is not 100%
>> white in either case and the difference is in line with what I would
>> expect if there was a sub-pixel shift..
>>
>> Scott
>>
>>
>> On Thu, Mar 6, 2014 at 1:51 PM, Phil Race <philip.race at oracle.com
>> <mailto:philip.race at oracle.com>> wrote:
>>
>> There really isn't any evidence of that. If it were true you'd see
>> the blending
>> into the pixels either side, but the pixels either side of the
>> stem are 100%
>> white in both cases. And examining the subpixels inside the
>> extremities of
>> the stem backs me up ...
>>
>> -phil.
>>
>>
>> On 3/6/2014 10:40 AM, Scott Palmer wrote:
>>
>> I think the stem of the L is colored differently because of
>> *sub-pixel* differences in its position. I.e. it appears to
>> be at the same integer position, but it isn't at the same real
>> position. It looks to me like that alone could account for
>> the differences.
>>
>> Scott
>>
>>
>> On Thu, Mar 6, 2014 at 1:35 PM, Phil Race
>> <philip.race at oracle.com <mailto:philip.race at oracle.com>
>> <mailto:philip.race at oracle.com
>> <mailto:philip.race at oracle.com>>> wrote:
>>
>> Does the evidence really support that ?
>> You only need to look at the first letter "L". The stem is in
>> exactly the same place isn't it? And yet the colours are
>> different.
>>
>> The overall length is different which I attribute to rounding
>> differences
>> or metrics differences used in accumulating the position
>> but that
>> is a guess.
>>
>> -phil.
>>
>>
>> On 3/6/2014 10:25 AM, Scott Palmer wrote:
>>
>> If you notice, in the images provided, the length of the
>> rendered text in pixels is significantly different
>> between the
>> two examples. That supports the theory that it is
>> simply,
>> sub-optimal positioning of the glyphs that is
>> resulting in the
>> more pronounced LCD anti-aliasing.
>>
>> Scott
>>
>>
>> On Thu, Mar 6, 2014 at 1:19 PM, Phil Race
>> <philip.race at oracle.com
>> <mailto:philip.race at oracle.com> <mailto:philip.race at oracle.com
>> <mailto:philip.race at oracle.com>>
>> <mailto:philip.race at oracle.com
>> <mailto:philip.race at oracle.com>
>>
>> <mailto:philip.race at oracle.com
>> <mailto:philip.race at oracle.com>>>> wrote:
>>
>> Perhaps the gamma adjustment is different ?
>> FX should pick this up from the
>> SystemParameterInfo SPI_GETFONTSMOOTHINGCONTRAST
>> setting.
>>
>> I don't know what Outlook (*) uses if its a WPF
>> app then
>> maybe its
>> picking
>> up an over-ridden setting for this from the
>> registry :
>>
>> http://msdn.microsoft.com/en-us/library/aa970267%28v=vs.110%29.aspx#gamma_level
>>
>> You should be able to check that out fairly
>> easily,and you
>> can use
>> this
>> JDK app to see what the SystemParameterInfo
>> setting is.
>>
>> import java.awt.*;
>> import java.util.*;
>> public class GetGamma {
>> public static void main(String args[]) {
>> Toolkit tk = Toolkit.getDefaultToolkit();
>> Map map =
>> (Map)tk.getDesktopProperty("awt.font.desktophints");
>> if (map != null) {
>> for (Object k : map.keySet()) {
>> System.out.println(k + " : " +
>> map.get(k));
>> }
>> }
>> }
>> }
>>
>> C:\>c:\jdk1.8\bin\java GetGamma
>> Text-specific antialiasing enable key : LCD HRGB
>> antialiasing text
>> mode
>> Text-specific LCD contrast key : 120
>>
>> (*) I'm sure Outlook used to be a GDI app, but who
>> knows what
>> version you are using
>> and what rendering technology it uses.
>> I've tried to make the point many times before that
>> someone can
>> always point to
>> a difference from 'native' rendering simply
>> because the
>> platforms
>> like OS X and Windows
>> have multiple rasterisers and multiple font
>> technologies
>> all of
>> which are different
>> from each other. So whilst any notably 'poor'
>> rendering
>> needs to
>> be looked into
>> it maybe sometimes an artifact of one rendering path
>> compared to
>> another ..
>>
>> -phil.
>>
>>
>> On 3/6/2014 1:21 AM, Robert Fisher wrote:
>>
>> Hi all,
>>
>> I think there is still room for improvement in
>> terms
>> of the
>> 'contrast' or 'vibrancy' of fonts in JavaFX.
>> Take a
>> look at
>> this example:
>>
>> http://i.imgur.com/6qSamTO.png
>>
>> I'm running Windows 7. What you are seeing is a
>> screenshot of
>> the default font, zoomed in 600%. The top text
>> is JavaFX 8
>> (latest build as of 3 days ago). The bottom
>> text is
>> Outlook
>> but could just as easily have been Firefox,
>> Chrome,
>> Word, or
>> Eclipse SWT - they're all indistinguishable to
>> me.
>>
>> The JavaFX text doesn't look as vibrant. In
>> particular the
>> smoothing algorithm seems to be making poor
>> colour
>> choices for
>> the vertical strokes. At 100% the difference
>> is subtle but
>> important.
>>
>> I have the text fill set to Color.BLACK and
>> the font
>> smoothing
>> type set to LCD. Is there something else I can
>> configure to
>> get more vibrant-looking fonts?
>>
>> Cheers!
>> Rob
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>>>
>> [mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>
>>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>>
>>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>
>> <mailto:openjfx-dev-bounces at openjdk.java.net
>> <mailto:openjfx-dev-bounces at openjdk.java.net>>>] Im Auftrag von
>> Stephen F Northover
>> Gesendet: Mittwoch, 5. März 2014 18:30
>> An: Pedro Duque Vieira; OpenJFX Mailing List
>> Betreff: Re: Poor font rendering..
>>
>> Hi Pedro,
>>
>> Font rendering in FX8 is using the native
>> rasterizer
>> so the
>> glyphs should be identical to what the
>> operating system is
>> rendering. That said, we may have a bug.
>> Please enter
>> a JIRA
>> with sample code and a screen shot of the bad
>> rendering. That
>> will give us something concrete to work with.
>>
>> Thanks,
>> Steve
>>
>> On 2014-03-05 12:10 PM, Pedro Duque Vieira wrote:
>>
>> Hi,
>>
>> As evidenced by the screenshots in
>> http://pixelduke.wordpress.com/
>> blog posts about JMetro, javafx as
>> noticeably poor
>> font
>> rendering
>> visuals. The most recent screenshots were
>> taken on a
>> windows 8.1
>> machine and the older ones on windows 7,
>> using
>> Segoe UI
>> (windows 7 & 8 system font).
>>
>> 1- As this been reported?
>>
>> 2- Is the javafx team working on it?
>>
>> 3- Is there something the developer can do
>> to increase
>> font rendering
>> quality?
>>
>> Thanks!
>> Best regards,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
More information about the openjfx-dev
mailing list