About those Unity stats, check also how much users use Windows vs OS X (it's about 90% / 10%). Then, as I said, check a few computer shops and keep in mind that “HD” means the dreaded 1366×768 resolution.
I would guess the majority of the users still uses the standard 96 DPI resolution. You can wish otherwise all day, it won't make it true.
--
Roeland
This detour into DPI is missing the point for me.. I've been arguing against hinting since way before high-DPI displays existed, and don't really care too much about that.
If I only had one sentence to make my case, it'd be this:
If you've built a GUI where the precise colour of individual pixels directly affects its usability, then your design is broken, not the rendering algorithm!
Sub-pixel differences may affect the overall aesthetics of a GUI, but should never be blamed for UX problems.
If you really need to support users on 1366x768 displays, then the problem you need to solve is not about font aliasing, it's about economy of design, UX, layout reactivity, etc. If you're squinting at pixels then you're focusing on the wrong thing.
The reason that I get so annoyed about this topic is because a few people make all this public fuss about the font rendering, and then when I see examples of what they want to do with it, it's always the same kind of ugly, cluttered, unimaginitive, hundreds-of-knobs-on-one-big-messy page type of GUI that I want to encourage people not to make!
The best modern GUIs never struggle to squeeze content into pixel-sized spaces, they use smart, adaptive, dynamic layouts and generous, well thought-out ways of presenting the minimal amount of relevant information clearly. These interfaces never seem cluttered. And the people who build those really great interfaces never bother me about font rendering.
Hello Jules !
I would have loved not to put fire on oil, but I think I have to give my opinion on this topic as well ;)
My main issue before with Font rendering was the differences you get between the display of the same code in Windows and Mac OS X. I have solved this issue a while ago by not caring too much anymore, or by using the setRenderingEngine function on Mac OS X, to remove the "blurry" signature of CoreGraphics Font rendering. Sometimes I still have issues between Windows and Mac OS X with the actual size of the Font being different, but it's a problem with some Fonts and not others, so I try not to use any Font displaying this issue.
However, at various times, I would have liked to be able to disable the anti-aliasing of the Font rendering, to display accurately small characters. I totally agree with Jules when he said that they shouldn't be used at all if possible in the plug-ins GUI, since most of the time it is needed to make labels for hundreds-of-knobs-on-one-big-messy page type of GUI, and that's a really wrong practice. But in my case, it is more something I do for "design purposes", not for displaying useful information, or things affecting the global layout, usability etc.
I have a typical example for that : the vu-meters. Even if you put a large one in your UI, you can't display the metering in dB all over the vu-meter with large font sizes, because that's not relevant to use a big part of your UI to do that. That's what is done in most of the DAWs and a few plug-ins I have in mind. To do that, I had to do some extra graphics work on Photoshop for clients, even if I would have liked to do it directly with JUCE. One time I even wrote a function which draws small number characters pixel by pixel...
Moreover, the ability to choose the way a font is displayed on screen is a very interesting design tool. That's why you can choose between 5 differents options on Photoshop for that (aliased, crisped, sharp, strong, smooth). It's a function I use all the time when I do something with Photoshop. Typography design isn't just a matter of putting some characters on a screen, and changing their style. I guess a lot of designers would be angry if Adobe removes all these options but one, with the argument they should use only this one, the others being bad design choices. What if I want to design deliberately an UI with a retro look, and have fun with all the retro codes, while keeping the usability under control ? Why should the content of a library impose me some design choices, just because some people might do wrong things with others ?
So Jules, I think at one time you will have to give up, and develop something allowing people to disable anti-aliasing, and the easiest way to do that on your side would be the best one ;) Either some extra code in JUCE just for the anti aliasing part (I couldn't care less about the hinting stuff personnally) or a wrapper for FreeType would be fine. This way you will also stop the 5 years flow of messages on this topic, which isn't totally there because of wrong ideas as you may think ;) You should also consider that maybe some very good designers doing a very good UI work would love to use this functionality, not just beginners or "unimaginative" people !
Anyway, if you don't want to, I will continue to use workarounds, and I don't think that's the most useful thing you can develop on JUCE right now, but I don't think you will ever stop the flow of messages about font rendering :)
“If you really need to support users on 1366x768 displays” — Well, duh. Unless you're sure nobody uses your app on a laptop. There are still a lot of laptops with that resolution on sale today. On a 15" panel. I can see the screen door effect on these screens from a meter away, literally. And Apple is still setting their standard 13" MacBook (with standard low-res screen) today.
Claiming that nobody is using low-resolution monitors anymore is just a straw-man argument, and easily shown to be wrong. If you make that claim, then of course you'll get some fuss.
Now back to the font question: what happens on Windows is that, depending on your ClearType settings, text on JUCE apps will look distinctively fuzzy next to the native UIs next to it. And people have different tastes, some will think one looks better, some will think the other looks better. But mainly, most will be used to how Windows renders fonts. So there will be questions about that from time to time.
And you can bet that Microsoft didn't implement ClearType and friends just for the sake of it. More likely they did a lot of UX testing, which has shown that this hinting + subpixel rendering improves readability.
--
Roeland
And you can bet that Microsoft didn't implement ClearType and friends just for the sake of it. More likely they did a lot of UX testing, which has shown that this hinting + subpixel rendering improves readability.
Well, tell that to the developers of Word 2013 !
Despite these improvements, Word 2013 stopped using ClearType. The reasons invoked are, in the words of Murray Sargent: "There is a problem with ClearType: it depends critically on the color of the background pixels. This isn’t a problem if you know a priori that those pixels are white, which is usually the case for text. But the general case involves calculating what the colors should be for an arbitrary background and that takes time. Meanwhile, Word 2013 enjoys cool animations and smooth zooming. Nothing jumps any more. Even the caret (the blinking vertical line at the text insertion point) glides from one position to the next as you type. Jerking movement just isn’t considered cool any more. Well animations and zooms have to be faster than human response times in order to appear smooth. And that rules out ClearType in animated scenarios at least with present generation hardware. And in future scenarios, screens will have sufficiently high resolution that gray-scale anti-aliasing should suffice."
Hi there!
I made an account just so I could point out that as it's nearly 2016, as you say, users have been complaining about Juce's blurry text rendering for nearly a decade now. Posts here from 2006 make the same complaint.
I should point out, too, that I'm not a Juce user solely for this reason. I'd love to use Juce for my projects (desktop graphics programs, generally), because it seems so ideal in so many ways, but I can't, because I find Juce's text rendering too hard on the eyes. Too hard on the eyes for me, and too hard on the eyes for my users. So every few months I check to see if anything has improved with regards to text rendering, and every time I leave disheartened.
I understand the need for the smoothest antialiasing when dealing with images, but I don't agree at all that text should be antialiased for smoothness above all else. Text must be readable, above all else, potentially for hours at a time. I understand, too, that Juce isn't intended for dense UIs, but the requirement for information density and tiny fonts already exists. You can't really expect all your (potential) users to rework their UI designs around Juce's shortcomings. There's no easy or performant way to make the rest of the UI as soft as the text. That means having to put up with a decidedly unpleasant mixture of crisp & soft elements in your UI. It's worse than having clashing colours you can't turn off.
Meanwhile, in rest of the Windows world, DPI has stabilised at around 100dpi for desktop monitors, and there's no sign that it'll go much higher, because it's easier and more useful to just get a larger monitor at the same dpi. In the Windows world, 100dpi is a solved problem, because Cleartype etc. keeps even tiny fonts legible. Everything from Chrome to Visual Studio presents its text at maximum antialiased sharpness at all sizes, and everyone seems to like it that way.
Granted, Microsoft have made some efforts to support higher-dpi monitors with Windows 8 & up, but the results have not been good. The common complaint is that (you guessed it!) the high-dpi feature renders text that's too blurry to read comfortably, in regions that are clearly mismatched with the windows around them. It's a step backwards. Show me a modern Mac and I'll have a similar complaint: text is harder to read on a 'retina' display than on a typical 100dpi monitor, and it becomes the ugliest feature on an otherwise quite nice-looking screen.
So text in Juce (and Juce alone, as far as I can tell) remains blurry on the assumption that an old problem that's already been solved will be solved again, perhaps in less than another decade, when everyone else has come to prefer higher-dpi monitors and replaced all their existing monitors... at which point the text in Juce will still be the blurriest part of any UI it's used in.
Isn't it time to add some official support for Freetype, vertical hinting and/or LCD optimisations? Or OS-native text rendering? It's clearly important to a lot of existing users, and it's a deciding factor for potential customers with money to spend. As you say, it's nearly 2016, and after roughly a decade, the world has still not agreed with you that blurrier text on a higher-dpi monitor is better than sharper text on the monitors we've actually got.
Or OS-native text rendering?
On Windows you can use DirectWrite or the software renderer by setting a define and on Mac OS X CoreGraphics is the default renderer, and it is a lot more "blurry" than the JUCE software renderer that you can get with setRenderingEngine(0)
