This problem (huge bounds and y-flip on paths created by GlyphArrangement) also happens on macOS on latest develop. It starts with this commit that also caused the font size issues. So much for less maintenance by removing deprecated functions… It looks like some needed code has been removed as well.
there’s a new line:
.transformedBy (AffineTransform::scale (1.0f, -1.0f));
that explains the y-flips I am seeing. Not sure why I get these gigantic bounds yet.
Thanks we will take a look at this first thing tomorrow.
In the meantime I found the reason for my path rendering glitch. That one was caused by my code and unrelated to recent changes. It showed up on Linux only because that is the only platform using the software renderer. I made a path and didn’t call closeSubPath() at the end. If the “opening” is on the left side, the software renderer does not fill the path correctly. d2d and CoreGraphics however seem to close any subpath automatically before filling, so it still worked on macOS and Windows.
So the only issue I see right now is incorrect paths (way too large and transformed) returned by juce::GlyphArrangement::createPath() - so this thread has kind of derailed.. I’m sorry. The original issue was solved, but this new one got added at the same time and I wrongly thought these are caused by the same change.
To demonstrate the remaining issue clearly I modified DemoRunner/GlyphsDemo like this:
GlyphsDemo (ControllersComponent& cc): GraphicsDemoBase (cc, "Glyphs")
{
glyphs.addLineOfText(FontOptions { 20.0f }, "The Quick Brown Fox Jumps Over The Lazy Dog", 0.f, 0.f);
juce::Path path;
glyphs.createPath(path);
DBG(path.getBounds().toString());
}
The drawing in the demo is unaffected (using GlyphArrangement::draw(), but the DBG() output and the path did change a lot.
before font change: 0.149254 -13.0929 390.953 16.5672
after font change: -2944.43 -7115.36 32468 33929.6
So I guess what broke is createPath() only.
Edit: inspecting the code more I think what is going on is that for GlyphArrangement::createPath() the coordinate system of the glyphs is no longer converted to “screen pixels”.
Seeing all the DPI modifications I just tried develop on windows and it breaks my plugin in several ways, both in standalone and vst3 
I have code to handle scale and DPI divergences between standalone and vst on windows, but I guess I am not alone doing that.
Can you please let us know all of the ways in which it’s broken?
The aim is that, for the general case, people won’t need to apply their own scaling and DPI fixes.
Getting scaling “right” on Windows is very difficult, and I’d rather not contemplate the cumulative amount of time the JUCE team has spend navigating this landscape over the years. That being said, once we’ve fixed this issue, I think we’re in a pretty good place.
It is a necessary endeavor indeed, but I am afraid it will break many current plugins that had workarounds in place to cope with the legacy behavior.
I will try to report on all the problems and fixes I can find. It looks like simply turning off my compatibility layer fixes a few problems already.
One big problem that remains is with native title bar in standalone, where moving or resizing the window makes it go crazy. I did not test with a generic plugin though.
@pflugshaupt thanks for reporting, I think both of the issues you’ve reported should now be fixed on develop
Beside the issue with native title bar in standalone, the other major issue I could track is some flashing while resizing when Direct2D is enabled.
Tested in Reaper with the GenericAudioProcessorEditor UI.
@anthony-nicholls Thank you for the quick fixes! I can confirm all the issues I saw are resolved.
@anthony-nicholls Argh, I wrote too early. After testing some more, I still see the strange letter size issue if the software renderer is used and rendering is at precisely 100% scale. I see this on Ubuntu and Windows (but it’s likely a general issue with the Software Renderer). This screenshot is from a Windows Build of the DemoRunner. Windows is set to 100% display scale and the Software Renderer is selected on the DemoRunner Settings pane:
Direct2D is fine. If the window is resized, there are correct frames in between bad frames. I guess somewhere in the code there is a check for 100% scale that leads to using the wrong letter size - your fix appears to be ignored in that special case. Unfortunately, on Ubuntu, it’s the normal case for things like alert windows.
Thanks, hopefully this issue should be resolved by the following changes:
…and this should also be fixed now:
The font-size issues in the software renderer should be fixed by this commit:
Thanks again for the bug reports!
Thank you, those two issues are indeed resolved!
I don’t see any other issue for now, but I will test further.
