This is the chicken and egg problem. You refuse to test but expect bugs to be found by others. If everybody thought like that, no bugs would ever be found, because nobody is around to test.
This is not true. I am very happy about the harfbuzz addition that solves a lot of spacing issues, but the rendering itself currently is terrible at small sizes. This is caused by Direct2D and the strange hinting options used. If you want to see what I mean, open the demo runner on Windows, run the font demo, select any font and adjust the size between 10 and 20 on a screen that uses 150% scaling or less on Windows. Some sizes are absolutely unusable for many fonts.
This is Arial Bold with 150% Windows UI Scaling going from size 20 to 10. Check out for instants the shape of the small āaā or āeā as they get smaller.
Direct2D:
Software Renderer:
1 Like
Both seem perfectly legible to me. We use quite small font sizes ourselves:
A change of this magnitude should have been in beta for far longer if we canāt enable or disable the chunks liable to cause issues. āYou refuse to testā - this is out of order, it is not convenient to test now and it wasnāt during the beta, but I have taken months out of my development schedule to test software for others in the past so I take offence to this, itās a lazy way to shut down a legitimate argument.
2 Likes
So you are willing to give it a try and form your conclusion? Because so far, youāve stated the oppositete. Iām confused.
This issue doesnāt affect all popups, itās only long menus with transparent backgrounds, so a bit of an edge case. In an app that uses opaque popup menus, or short menus, you wouldnāt see issues. This is probably why the issue wasnāt caught until after release.
Although there is quite a bit of noise about Direct2D on this forum, Iād say that the majority are things like this that wouldnāt affect most apps, and which have workarounds for the moment. We have a handle on most of these issues, with fixes incoming.
The font rendering in the software renderer is not particularly sophisticated, so Iām sure we can improve text rendering with D2D. Exactly how we do this (surfacing more options, picking different defaults, something else - maybe weāre forgetting to pass the screen DPI to D2D at some point) requires some investigation. In the meantime, Iād be interested to see how the same font appears at the same size in other D2D-enabled apps (Chrome?).
We are a part of a community. Some people have the time to try things now, others do not, stop deliberately obfuscating the root issue here.
1 Like
Being legible is not the only concern when it comes to fonts.
The y-hinting makes it look like 20 different fonts, and most of them are fugly. The image you posted looks very soft in comparisonā¦ are you certain those lines were rendered to the screen by d2d without any image rescaling etc.?
No, it was scaled down to 50%, because I work with 200% and didnāt want it to appear huge. Here is an unscaled version:
On my monitor, it displays at half the size, and thatās how it then looks for the user. I donāt see the point of zooming in to 400% and then complaining about individual pixels the user couldnāt even possibly see, unless he took a screenshot and also zoomed in.
I can scale our entire UI, and I never see any hinting issues, and that is because we picked fixed font sizes (labels = 12.5px, etc.) and then use a transform for the entire UI. The font gets converted to Glyphs at the size specified and then they are transformed during painting, so no matter what size I use so it always looks good. So sudden jumps, etc.
Yes, Iām sure it was rendered by D2D. The font is called āInterā
So you are saying you are converting the text to paths and are scaling those?
Then I canāt take your arguments for or against a D2D feature flag seriously. You request a major change, with major ramifications, based on conjecture and hearsay.
It would take you an hour or less to clone the latest develop branch, change a couple of font objects (because their default constructor has changed), and try it out for yourself. See if you have any problems.
No, JUCE does that. I would be very surprised if they scaled the font size before it came to rasterization.
Chrome uses Skia which probably ends up using Direct2D. It definitely uses different settings than Juce8 at the moment. The only thing I see in the J8 sources is that text antialiasing is set to use āGrayscale Antialiasingā. However Chrome does use Subpixel antialiasing by default. There are ways to pull the cleartype monitor configuration into Direct2D, but I didnāt manage to add this to J8 quickly as it is very complicated. I would assume Chrome by default does that.
1 Like
Have you updated your Font constructors to use the new metrics and not the ālegacyā ones?
Of course. That is the first thing I did.
Btw. If I work on a 200% scaling Windows machine Iām also happy with the font rendering.
When running the font demo with 100% scalingā¦ things get really ugly in the font list.
And yes Iām a font nerd and totally OCD when it comes to fonts.
I do think itās possible to make the D2D font rendering look better than the legacy software renderer, but as it stands we are not there yet.
2 Likes
btw. I retract that criticism. This was caused by images being converted pixel by pixel for some reason - and we already know pixel data manipulation is not recommended with d2d.
I am delighted your upgrade went smoothly. Perhaps mine would too. I am sure many have. Frankly it is an irrelevance because clearly that is far from a universal experience and I have respect for others that have reported problems that they cannot yet resolve and clearly are legitimate issues. Perhaps you are willing to write those off but I am supporting those that would prefer to be able to adopt major features gradually, it is the right thing to do, given that all development on v7 has been stopped. I think an āwell Iām alright guvā attitude is one that we can collectively do better than.
Direct2DGraphicsContext::drawGlyphs does apply a transform, but nothing specific to D2D; the software renderer applies a similar transform.
I think adding more support for text rendering controls would be worthwhile; not sure how to handle the cross-platform issues.
There is still considerable room for improvement; I think we could significantly reduce the VRAM footprint, which would in turn help with performance.
Matt
2 Likes
You can disable most of the Direct2D right now without making any changes to JUCE.
As @reuk mentioned you can set the current rendering engine through the component peer. See the example code below.
You can also explicitly create a software bitmap by specifying the image type in the Image constructor:
auto image = juce::Image{ juce::Image::ARGB, 100, 100, true, juce::SoftwareImageType{} };
Of course, that doesnāt help with the JUCE classes that create images internally such as ImageCache; I expect that will improve once large image support is implemented.
Matt
1 Like