A better way to render a text

Hi Jules.

JUCE renders text badly in many cases. Sometimes letters look ugly and partially faded.
I wish JUCE renders a text like this article suggests http://www.antigrain.com/research/font_rasterization/index.html
I hope the info will be valuable for you, Julian.

The code I checked-in yesterday has a new glyph engine that renders text with 100% accurate sub-pixel positioning and perfect anti-aliasing. It doesn’t (yet) have adjustable gamma, but in every other way renders text perfectly.

Interestingly, the edge table techniques I used mean that I should also be able to add cleartype-style LCD sub-pixel rendering for both text and paths with very little overhead, so I’ll be experimenting with that soon.

excellent stuff ! the improvement is very noticeable, the fonts are much crisper with the new version !

1>c:\devel\ctrlr\gekon\gekonlookandfeel.cpp(128) : error C2065: 'GradientBrush' : undeclared identifier
1>c:\devel\ctrlr\gekon\gekonlookandfeel.cpp(128) : error C2146: syntax error : missing ';' before identifier 'gradient_1'
1>c:\devel\ctrlr\gekon\gekonlookandfeel.cpp(128) : error C3861: 'gradient_1': identifier not found
1>c:\devel\ctrlr\gekon\gekonlookandfeel.cpp(133) : error C2039: 'setBrush' : is not a member of 'juce::Graphics'
1>        c:\devel\juce\src\gui\graphics\contexts\juce_graphics.h(55) : see declaration of 'juce::Graphics'

looks like setBrush and other Brush related stuff is not there.

Yep, the brush classes are now officially gone. You can still get all the same functionality (and more), but you just have to call different methods.

I’ve got some more check-ins on the way shortly that’ll also let you do transformed image fills, which is pretty cool.

the Brush folder and files are still referenced in the Xcode proj…

Really? Maybe Could have sworn that I checked in the xcode project… Anyway, I’ll be checking in more stuff today so will double-check that.

Yep… just cloned a clean copy from GIT this morning.

The text is looking better! (The MaxMSP people will be pleased!)

Still having trouble with antialiasing the lines - I will try this on another machine this week (haven’t had chance yet).

[quote=“martinrobinson”]
Still having trouble with antialiasing the lines - I will try this on another machine this week (haven’t had chance yet).[/quote]

Thanks - I’d love to get to the bottom of that!

Sorry, but I’ve not seen any visual differences between the old and the new way of how JUCE renders text. And yes, I’ve pulled the last JUCE revision.

The new glyph engine renders like this:

…but I’ve expected to see something like this:

What do I do wrong?

I never said it was LCD-optimised - I said I was going to look into that soon.

Not sure what exactly you were expecting, but the anti-aliasing is now perfect (previously, it used fewer grey levels), and the sub-pixel positioning is perfect (previously it was only within 0.5 pixel).

I see it like this on the Mac:
[attachment=0]Picture 1.png[/attachment]

Well yes - if you use the CoreGraphics renderer, you’ll get the mac’s glyph rendering, which does use LCD optimisation (unless you have two monitors, like me… why is that?)

[quote=“jules”]I never said it was LCD-optimised - I said I was going to look into that soon.

Not sure what exactly you were expecting, but the anti-aliasing is now perfect (previously, it used fewer grey levels), and the sub-pixel positioning is perfect (previously it was only within 0.5 pixel).[/quote]

Oh, I misunderstood you, my fault.

BTW, your new Code Editor component is the magic. Really, I fell in love with it (despite it is in its early alpha stage). You’re a magician, Julian! :wink:
I opened the 8Mb juce_amalgamated.cpp file at the Code Editor demo page and I was amazed by the speed and ease with which I managed to edit the source code. You are my hero, Julian. :smiley:
I’ve noticed a little bug in the Code Editor component. When I press the Tab button, the component places the text cursor and the tab character at the next following line (like “\n\t” instead of “\t”).

Thanks - it’s all done with sheer cleverness rather than actual magic, though.

Good call about the tabs being messed up - I’ve not had chance to spend much time on the code editor yet, but it’s going to be an important element of the jucer 2.0…

Hello Jules, do you have any words on that? It’s a matter of personal preferences, and I very much prefer Cleartype rendering to JUCE’s current font rendering, so I wonder if it makes sense to wait for it.

It’s something I’d enjoy playing around with, although I’ve got a lot of higher-priority stuff on my to-do-list first so not sure how soon I could promise anything there.

+1
don’t want to push, but cleartype support would be a very nice thing to have indeed