Lucida Console: IntroJucer versus Visual Studio


#1

No comment necessary.

[attachment=0]TextComparison.png[/attachment]


#2

looks good~


#3

Isn’t it a difference of hinting ? it seems much stronger in the VS version than in the juce version (notice how the ‘C’ are drawn with a straight 1px line on the top and bottom. Also the ‘nC’ in buttonClicked is almost joined in the VS version). I’m not necessarily a big fan of too much hinting.


#4

Yeah, it looks like hinting is helping, but there’s also LCD optimisation helping the horizontal resolution. Zoom in on VS so you can see individual pixels and you’ll see different colours at the edge of the glyphs. Look at IntroJucer and you’ll see it’s monochrome.


#5

IntroJucer:

The tops of the capital O’s, C’s, S’s, etc look bad. Appears the hinting isn’t working on vertical axis.
The capital M’s and H’s are unusable and warped – the left side vertical line is thin and clear, while the right side vertical line is thick and blurry. Inconsistent.
The hanging tail of the lowercase g’s have some odd shrapnel pixel pattern, looks bad.
The capital F’s middle horizontal line looks unusable, horrible, blurry. Just this middle horizontal line of the F alone is enough to kill this off.

The dotted i of ‘Config’ disappears into a motion blur.

The small e’s on the left hand pane are a joke. The hole in the middle of the e disappears into a blur of wet paint.
The center section of the big M’s on the left hand pane turn into some freak square shape.
The small t’s as in ‘CGradient’ are destroyed and you can barely see the top tick. It’s just a weird defocused blob of failure.


#6

Maybe also gamma correction is part of the issue here, for example the middle horizontal line of the ‘F’ is noticably darker than the rest of the F.


#7

It’s not a gamma issue, it’s that he’s trying to draw a line half way in between the two pixels, and then compromising with antialiasing by drawing darker colors on each pixel and hoping the human eye will merge them together into one brighter line.

The error Jules makes is by not realizing that this method of rendering does not work at this font size and resolution, and yet this font size and this screenshot’s resolution is perfectly reasonable – and indicative of how most people will use JUCE.

How hard is it to realize that we factually aren’t 640x480 users? And that the rendering method JUCE uses factually does not perform well at the resolutions we are using in reality?
It’s not hard. You have to be seriously far gone and very far down a hole in denial to be able to block this simple logic out of your mind or be unable to see it.


#8

[quote=“Zola”]
How hard is it to realize that we factually aren’t 640x480 users? And that the rendering method JUCE uses factually does not perform well at the resolutions we are using in reality?
It’s not hard. You have to be seriously far gone and very far down a hole in denial to be able to block this simple logic out of your mind or be unable to see it.[/quote]

Then do work with TheVinn to further his FreeType stuff and use that.


#9

I posed the question a long time ago, regarding text rendering with and without hinting. It has been definitively concluded that hinting helps for a variety of popular use-cases. Jules disagrees but that does not change the result. Note that hinting is even more important for non Roman fonts (like kanji).

Will hinting become obsolete in the future as resolution of displays increase? Maybe. Jules says yes, while I say no. This is all speculation and can’t be proven either way.


#10

Why doesn’t Jules show support for a Freetype patch or say he’ll adopt it as the official font rendering system of JUCE?
I don’t understand why he doesn’t listen to the users?
Isn’t the purpose of a good text rendering system to make it easy for us, the users, to read the text?
If we report there’s issues with the readability, how can we be “wrong”?


#11

[quote=“Zola”]Why doesn’t Jules show support for a Freetype patch or say he’ll adopt it as the official font rendering system of JUCE? I don’t understand why he doesn’t listen to the users?
Isn’t the purpose of a good text rendering system to make it easy for us, the users, to read the text? He just doesn’t care what we think?[/quote]

I can’t speak for Jules but based on his comments in older threads regarding hinting, it seems he has an ideological objection to the idea of munging the vector representation of glyphs to make them appear better on a raster grid. I totally understand where he’s coming from: Rendering text is messy business!. It is much more elegant to just leave the curves alone and be resolution-independent.

There’s another problem with hinting, which is that it breaks down when you have a transform on the viewport. Imagine scaling/rotating a hinted glyph. It will typically look terrible. Jules likes robust code that works for all cases and has no rough edges. Adding hinting would definitely complicate things. It might also make new features a lot more difficult to implement in the future. And if he adds hinting then he has to support it for the rest of JUCE’s life. This means that any bugs related to TextLayout and hinting will have to be fixed.

So I don’t think it’s a matter of not caring, probably its a matter of just hoping that this problem will go away in the near future with improvements in display technology. Also, I believe that when JUCE uses the operating system to render the text (OpenGL / CoreGraphics / Direct2D?) it gets hinted by the OS. Although I can’t be sure.

These are my opinions; to really know, Jules would have to weigh in on it.

Either way I think you should just leave it alone. I’ve provided a workable solution that many people (myself included) are using to get around this problem in their plugins and apps. Everything that can be said about hinting, has been said about hinting. There is really not much more that can be added, just search through the old threads for “hinting” and “Freetype.”


#12

What would be the downside to providing two clearly labelled and easy to understand text rendering methods as a core feature of JUCE, to be freely picked between by JUCE users?

These are just comical names, but

  • HintedTextRenderingMethod
  • TransformIndependentTextRenderingMethod

Wouldn’t this be beautiful if a user could just go "Hmm. I need a nice Text Editor Control. Let’s see. I’ll pick the HintedTextRenderingMethod"
or “Hmm. I’m making a cool canvas graph UI that you zoom in and out of or rotate frequently, let me pick the TransformIndependentTextRenderingMethod”

By providing both methods as clearly labeled core features of the library, no prediction about the future is even necessary and so we avoid the whole debate – nor do we even need to make any assumptions about WHERE the library will be used.
Perhaps somebody wants to render some text on a cool retro synth’s front backlit panel which will never zoom or rotate, features a fixed resolution, and they desire HintedTextRenderingMethod to align with those nice square pixels?
Even if displays begin to ship with higher resolution, why assume that everybody has to be on such a high resolution desktop display for every use case?
How can providing the HintedTextRenderingMethod harm any code base which needs it or desires it?
It’s a feature! A utility! A useful thing to have amongst many other utilities, all of which users can pick and choose.
Isn’t JUCE supposed to provide many things which not necessarily every user must choose to use?

I just want a choice.


#13

Nothing, if you extend the idea of “core feature of JUCE” to include freely available third party modules which are easily integrated into IntroJucer. Although Jules grumbled the whole time, he did add the support I needed for FreeTypeFaces to work (some tweaks to the GlyphCache and Typeface classes).

I think that when Jules has more time and finally implements robust IntroJucer support for third party modules you will see things like this happen.


#14

How long have you been programming? If Jules commits to supporting the “HintedTextRenderingMethod” then whenever he adds new features he has to make sure that he doesn’t break this piece of code. Since hinting and type layout are rather non-trivial (even my FreeTypeFaces has some serious warts, especially when it comes to kerning pairs), it is almost a certainty that guaranteeing to JUCE users that HintedTextRenderingMethod will always work will result in increased maintenance costs.


#15

That’s what I call a gamma issue. The two pixels line is too dark, gamma correction should be taken into account when antialiasing


#16

I totally disagree, it is the responsibility of the operating system / user to adjust their display settings to yield a consistent display gamma.


#17

Maybe I’m wrong, I’m not at all an expert on this topic, but I think this is the same issue as when resizing an image , as explained here: http://www.4p8.com/eric.brasseur/gamma.html . This part is especially striking : http://www.4p8.com/eric.brasseur/gamma.html#colors . When resampling a picture , one should work in the linear scale, and then go back to the sRGB scale when storing the pixel values (since screens do not use a linear rgb scale), and juce does not do that . But maybe I’m missing something, as I said I’m no expert and I don’t know the internals of juce rendering.


#18

Yes, that is true except for the part about screens not using a linear rgb scale. The whole point of monitor calibration is to make sure that your screen is adjusted to give a linear RGB response (or else you’re getting less than 8 bits per colour component of luminance information). This way, applications and library like JUCE can just work in linear RGB.


#19

Are you sure of that ? Mine are certainly not linear since when I look at http://www.4p8.com/eric.brasseur/gamma.html#colors , for me the “good” one (the one which looks like the picture above when seen from a far distance) is http://www.4p8.com/eric.brasseur/gamma_colors_good.jpg and the bad one is http://www.4p8.com/eric.brasseur/gamma_colors_gimp.jpg , on all my screens (which I have never tweaked)