OpenGlContext makes drawing filtered

1

It seems that attaching my component to an openGl context affects the drawing. It seems smoother, not pixel perfect. My code is simple:

    MainContentComponent::MainContentComponent()`
    {
        setSize (1920, 238);
        mImage = ImageCache::getFromMemory(BinaryData::RealFull_png, BinaryData::RealFull_pngSize);
        openGLContext.attachTo(*this);
    }

    void MainContentComponent::paint (Graphics& g)
    {
        g.drawImage(mImage, 0, 0, getWidth(), getHeight(), 0, 0, mImage.getWidth(), mImage.getHeight());
    }

If I remove the openGLContext.attachTo(*this);, the rendering of my image (right) is similar to the original image (center).
comparaison

Can I setup the OpenGl context to render the images exactly as they are? Juce 5, OSX.

2

Well, GL’s image mipmapping will be a little bit different from CoreGraphic’s. But I had a quick run of the demo app’s 2D demo, flipping between GL and CoreGraphics for the static RGB image, and it looks pretty much identical to me.

But you know
 I can’t see the rest of your image, but it really doesn’t look like something you should be using bitmaps for. If you’re drawing anything as simple as a rounded rectangle border, the only sensible way to do it is with vector graphics.

3

The full image is a HD keyboard, (1920x238).
RealFull

Looking at the corners of the keys in my comparison image, posted before, it is clear that we lose the crispiness of the image.

I cannot find the demo you are talking about in the exemples folder. Is there a difference with my code? Is my only option to come back to CoreGraphics, to keep the fidelity?

4

Just run the big demo app and choose “Graphics: 2D rendering”. You can swap the renderer at any time by pressing the ‘2’ and ‘3’ keys. Certainly there’s not much control over how GL filters the images, but you could tweak it by nudging it around by sub-pixel amounts, it could just be that CoreGraphics is snapping the position to a pixel boundary differently.

5

Tank you. I realized that drawing the keyboard myself in openGl and using a GL_NEAREST Texture Mag Filter actually has the result I am looking for.

If we want to keep the component system, the speed of openGl and the sharpness of CoreGraphics, this parameter seems to be set hard in the juce_opengl module, in OpenGLTexture::create.

As for a maintainable way to modify a native module, branch from the JUCE repo?

6

Would it help to add a setTextureMagFilterMode method to the OpenGLContext class?

7

That would be great. I think this is a necessary feature.

See the graphic: left is the current JUCE version, middle is the original file, right is with the NEAREST mag filter.

53
Screen Shot 2017-10-19 at 18.48.53.png1580×594 35.1 KB

Fidelity is more respected with that filter, and it is knows to be faster.

8

Hmm, the size of those three window buttons in each window make me wonder whether some antialiasing/blurring has took place when magnifying those images in the leftmost and rightmost cases

9

OK. I’ve added a new method called OpenGLContext::setTextureMagnificationFilter on develop with commit 159ffb5.

1 Like