OpenGL: Debug vs. Release? (Fonts/Mac)

General JUCE discussion
1

Edit: I found the Problem!

Seems like OpenGL is not compatible with OSX compatibility version 10.4!

Fonts get screwed up there!

Thank god I do not need this anyways!

Cheers!

 

------OP-----

 

Hi there!

//very simple usage 
UI::UI() { gl.attachTo(*this); } 
UI::~UI() { gl.detach(); }

I'm just trying the OpenGL renderer to do my regular component painting, e.g. just attaching a context to my topmost component, no custom OpenGL code. 

 

On my Mac-Release builds "most"** fonts are rendered way too small!

When I'm hovering a control, which triggers a regular repaint, the font suddenly have the correct size.

Seems to me that the font sizes get screwed up only on the very first "just made visible" paint, if that makes any sense.

In the Debug build all looks good thought. 

Again, no custom OpenGL rendering happening, just plain old JUCE painting.

Does not happen on Windows either. I checked my code for reasons, but it seems to me it lies inside JUCE as it does only happen if I enable OpenGL and in Release builds on Mac and my code has no relevant _DEBUG switches.

P.S.: I have a Retina display and run it at 2048 x 1280 via "display menu", thought setting it to regular scaling did not fix it, thought it seemed to lessen the degree to which the font size is off.

JUCE version == latest from GIT

Any Ideas?

 

Cheers!

 

EDIT: Sorry, I just reread the bug report guideline and are off to check the demo code now. Still, seems like a valid "bug" as Release and Debug certainly shouldn't be different.

EDIT2: While the demo seems to work just fine, it is a behaviour that shows precisely in contrast of the debug and release builds, and only if  I enable the OpneGL context. So it certainly is a bug.

EDIT3:I went through the whole code now (mine & JUCE), searching for any occurrence of _DEBUG (and related text). Nothing that could explain the differences observed :/

 

**components that are "setBufferedToImage(true)" do render their fonts correctly, as they presumably use the software render to produce the images that get passed to OpenGL.

 

JM

2

Hi dasdeck,

I realize this is an old post, but I believe I’m seeing similar behavior on the latest tip using the OpenGL 2D renderer on OSX 10.11 on a retina display. When you say that fonts are rendering small, do you mean thin, with a very narrow stroke width? It’s almost as though it’s rendering to a buffer that’s twice as big, and getting shrunk down. I can fix it by using setBufferedToImage(true) as well, which I believe uses a different lowLevelGraphicsContext to do the rendering.

I’m not sure what you mean regarding OSX compatibility version 10.4. I’m testing on OSX10.11 and using 10.11 as the OSX Deployment Target too.

3

You could also view it as the CoreText rendering the fonts as too thick. The native rendering uses the CoreText to render the fonts which has some subpixel anti-aliasing that makes fonts really quite bold, If you draw into an image the software renderer also has some subpixel anti-aliasing but it’s much more subtle. I think Jules has commented that he’s never been able to work out exactly what Apple are doing to achieve their font rendering. The OpenGL renderer appears to me to be different still and use grayscale subpixel anti-aliasing. Drawing into an image before rendering to screen should produce the most consistent results. Also if you make a smart cached image drawer for text that caches images of all the text that has ever been drawn and draws into images of a minimal size, you should find that drawing an image is faster than drawing the text (at least with tests I have run on mac).

4

It might be the CoreText antialiasing but the stroke width issue is significant and it doesn’t appear on Windows using the openGL, DirectWrite, or juce Software renderer. It’s only on OpenGL on Mac and the stroke width appears to be up to 2 pixels narrower. This is a particularly narrow stroke font, but heavier fonts have the same reduction, most of them looking like they’ve gone from a bold to regular, or regular to narrow weight.

This image is the OpenGL renderer on top and the CoreText renderer on bottom. FWIW, these fonts are compiled in to BinaryData, and this font only has 1 weight, so I’m certain it’s not just choosing the wrong weight. The difference appears to be in which type of LowLevelGraphicsContext is used.

Thanks for the tip regarding rendering to images, I’ll look into this as a work-around.