On 27/08/2013 17:59, Felipe Heidrich wrote:
Hi John
Thank you for the images!
Comparing DirectWrite versus T2K for grayscale text the main difference that
jumps at me is that in DirectWrite (which is what you get when prism.text=t2k
is not set) the glyphs look a touch taller, looking somewhat stretched.
Inspecting it closely you can see the actual pixel size is the same, it is the
anti-aliasing at the top that is different.
I'll see if anything can be done differently in DirectWrite to avoid this
'stretched' look, would that be better ?
The stretched look doesn't really bother me, it was just something that
changed (the apparent height) that I couldn't put my finger on. What
botheres me more is that the bolded glyphs (especially the "2") look
wierd, the thickness of parts of the same glyph seems to vary (not just
the "2" is affected, more glyphs look a touch worse, especially in the
top bar in my first screenshot:
http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png -- the legs of
the M and H for example have different thickness.. the "2" jumps out though)
Whether those are result of the stretched look or not I cannot say. I
can also imagine that if you're using DirectWrite that there's little
that can be done about it. Are there any advantages of using DW over t2k?
DirectWrite LCD for me is the one that gives the best result. That said, that
is something wrong going on in the text over the progress bar.
Yes, DirectWrite LCD certainly looks crisp, unfortunately I cannot use
it as my target is not an LCD screen.
I think however I know now what causes the text bug in the progress
bar. It's not really a progress bar, but just memory bar with text on
it that's supposed to be readable no matter what using an inversion
effect... It's this effect that I suspect causes problems with the
tricks used for LCD rendering, as a simple inversion of LCD rendered
glyphs is probably not gonna give the desired smooth result.
It's basically this, a Rectangle (with some CSS styling) and a Label in
a StackPane. The BlendMode.DIFFERENCE is what I suspect is causing the
issue. If so, LCD rendering may have to be disabled in these cases:
private final Rectangle memoryBar = new Rectangle();
private final Label memText = new Label();
private final StackPane gc = new StackPane() {{
getStyleClass().addAll("element", "memory");
getChildren().add(new StackPane() {{
getStyleClass().add("bar");
getChildren().addAll(memoryBar, memText);
}});
memText.setBlendMode(BlendMode.DIFFERENCE);
memoryBar.setWidth(150);
memoryBar.heightProperty().bind(memText.heightProperty());
}};
Is it possible to run the same test case on Mac ? (Grayscale text,
prism.text=t2k *not* set).
Unfortunately, I donot own a mac, and can't easily borrow one at this time.
--John
Regards
Felipe
On Aug 22, 2013, at 12:54 PM, John Hendrikx wrote:
On 22/08/2013 17:38, Felipe Heidrich wrote:
John, for the sake of testing.
Could you enable LCD text for the plot Label in your app ?
Please let me know if that improves the position of each glyph (relative to one
another).
You should also try your app using our previous text rasterizer, run with
-Dprism.text=t2k
Is that better for you ?
Sure, I've created approximately the same shots with different settings for
comparison:
prism.lcdtext=false
http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png
prism.lcdtext=true
http://ukyo.xs4all.nl/LCDSmoothed.png
prism.lcdtext=true, prism.text=t2k
http://ukyo.xs4all.nl/LCDSmoothedT2K.png
prism.lcdtext=false, prism.text=t2k
http://ukyo.xs4all.nl/GrayscaleT2K.png
Now that I compared them all, the last one is how it was for the longest time.
Now I also noticed that in the last shot the font height is a pixel smaller,
which is one the changes I couldn't put my finger on.
The LCD smoothed versions look quite good, but (as you can see in screenshot 2)
it for same reason garbles my memory indicator when the background image is
fading in. After the fade-in completes, the text is correct (I screenshotted
it just before the fade-in completes to show the garbled text). This occurs
with both the normal and t2k renderer when LCD text is on.
So, to make it clear:
1) Grayscale only: some glyphs look akward when bolded
2) Grayscale only + t2k: this is how I expected it to be (I tuned the look for
that). Apparently this default has changed(?). The font in the top bar seems
to be 1 pixel less high then in all the other version.
3) LCD only: Looks quite good on my normal LCD screens (better than Windows in
my opinion, but perhaps the light-on-dark vs dark-on-light is the cause of that)
4) LCD only + t2k: Also looks good, I think (3) looks better though
3+4 fail when I drag the Window to my projector. Colored fringes are visible.
This is probably a driver problem as Windows may not realize that my Projector
is not using LCD (DLP projector). I'm not sure how JavaFX figures this out,
but I assume it asks Windows for this information.
--John
Regards,
Felipe
On Aug 22, 2013, at 7:05 AM, John Hendrikx wrote:
Those are all normal controls, the plot section is just a Label for example.
On 22/08/2013 13:39, John C. Turnbull wrote:
John H, it may be just me but pretty much *all* the fonts in your screenshot
look quite poor and noticeably different from native font rendering. If you
look for instance at the text in the "Plot" section, to me that text looks
awful.
Is that inside a WebView or some other control?
-jct
-----Original Message-----
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of John Hendrikx
Sent: Thursday, 22 August 2013 17:29
To: openjfx-dev@openjdk.java.net
Subject: Re: Poor quality font rendering
I took another good look, and I see what is bothering me is mostly how the
glyph "2" is rendered on my system (it has a thick appearing curve attached
to the base). I've included a screenshot of my application that uses
several different sizes fonts, but it seems only the ones in the top bar are
rendered somewhat wierd.
http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png
I'm on Windows 7, JavaFX 8b99, 32-bit, using D3D pipeline (I get this stuff
in log in an infinite loop, so must be D3D I think):
D3D Vram Pool: 129,613,674 used (48.3%), 129,613,674 managed (48.3%),
268,435,456 total --
com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:134)
75 total resources being
managed
-- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:153)
4 permanent resources
(5.3%)
-- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:154)
2 resources locked
(2.7%)
-- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:156)
43 resources contain interesting data
(57.3%) --
com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:158)
0 resources disappeared
(0.0%)
-- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:160)
I also have this in main, before Application.launch is called:
System.setProperty("prism.lcdtext", "false");
In .root in CSS I have:
-fx-font-family: "Arial";
-fx-font-size: 16px;
-fx-font-weight: normal;
So all the fonts you see should be Arial (but the sizes and weights are
tweaked depending on location).
--John
On 21/08/2013 20:51, Felipe Heidrich wrote:
John H:
In JFX we decided to go with sub-pixel positioned text (as opposite to
pixel grid aligned).
That said, on Windows for grayscale text, we are not doing that (yet). Are
you running Windows, with D3D pipeline ?
I would need to see a picture to be sure I understand the problem you
describe.
Felipe
On Aug 21, 2013, at 10:19 AM, John Hendrikx wrote:
I think I also noticed a change in font rendering around b99 somewhere...
the fonts seem to be thinner than before, or perhaps more poorly aligned
with pixel boundaries. I'd prefer glyphs laid out in the same way each
time, ie. letters are always on a new pixel boundary, so the same letter
will look the same regardless of what preceeds it. I have LCD rendering
turned off as I donot appreciate colored fringes on my glyphs.
On 21/08/2013 14:53, John C. Turnbull wrote:
I have only really tested JavaFX extensively on Windows so my
comments here apply mainly to that platform.
It seems that even with a font smoothing type of LCD, font rendering
in JavaFX is not at the same level of quality of native
applications. My current experiences are with JavaFX 8 b103 and I
find that all rendered text in JavaFX appears of a significantly
poorer quality than that which I would see in Word for example or
even in IE10 (which I believe uses the same text rendering engine).
Also, these observations are based on text in "standard"
controls and the quality of font rendering is dramatically worse
within the Canvas control.
I am not an expert in font technology but I have read many times
that the levels of antialiasing for text that can be achieved in a
GPU-based renderer are always going to be less than that achieved in a
CPU-based renderer.
This is often explained on the basis of graphics card drivers being
optimised for performance and the rapid rendering of triangles
commonly required in games rather than for rendering quality when it
comes to text.
Is this the reason why JavaFX font rendering appears less legible
and of a lower quality than native apps?
If so, how does IE10 for example achieve a higher quality of
rendering when it seems to also use DirectWrite?
Is the quality of JavaFX font rendering ever going to improve?
Thanks,
-jct
