OpenGL Artifacts/Bug

In my app I see various artifacts when using OpenGL, on both macOS and Windows.

Since I can’t share screenshots of it here, I managed to reproduce some of these problems via the Demo by dragging the corner in the Transforms demo.

Could these maybe be related to the change to the EdgeTable size growing I co-requested? It looks like a bug in converting paths to scanline edges. In that case it would probably also happen on windows without OpenGL.

Which kind of GPU do you use? I can generate glitches with the OpenGL renderer and my onboard Intel GPU when I just trigger repaint very often. When I run the same code on the dedicated Nvidia GPU everything looks fine. I reproduced this behaviour on other laptops with an onboard Intel GPU.
I noticed this already with earlier juce versions. So this is definitely unrelated to the EdgeTable size changes. Since various OpenGL debuggers do not spit out any errors I assume that this is an Intel driver bug. Annoying anyway…

This screenshot is with my Nvidia GTX590. Others on my team see the same on their mac laptops, each with an Intel GPU of some kind.

This is no doubt EdgeTable related, as only it generates scanlines like the artifacts we’re seeing. Not sure if it’s related to the latest changes, as we have seen bugs like this for several months now - low priority stuff that would only show up once in awhile.

Ok. So the issues I am observing seem to be something different.

Maybe, maybe not!

FYI, I’ve tried with and without continuous repainting, likewise with multisampling and not, and different mag filters, and still get similar artifacts.

        openGLContext.setOpenGLVersionRequired (OpenGLContext::openGL3_2);
        openGLContext.setContinuousRepainting (true);
        openGLContext.setMultisamplingEnabled (true);
        openGLContext.setTextureMagnificationFilter (OpenGLContext::linear);

        //This is needed to enable multisampling on Windows:
        OpenGLPixelFormat pf;
        pf.stencilBufferBits = 8;
        pf.multisamplingLevel = 1;
        openGLContext.setPixelFormat (pf);

Can you check if this has something to do with this commit?

Rolled back to the commit just before it and am still seeing the same type of thing.

TBH, I rolled JUCE back to even as far as 2015 and saw the same kind of thing.

My feeling is that this has something to do with how the frame buffer is being cleared.

You’re probably better off clearing the whole frame/viewport instead of specific subregions.

@fabian I’ve just tested this out:

    void paintComponent()
        // you mustn't set your own cached image object when attaching a GL context!
        jassert (get (component) == this);

        if (! ensureFrameBufferSize())

        RectangleList<int> invalid (viewportArea);
        //invalid.subtract (validArea);
        //validArea = viewportArea;

and no artifacts are found in the JUCE Demo, nor my apps.

I understand this is bruteforce clearing, but may serve as a hint in the right direction!



Fabian and I both stared at this for a few hours and gave up! Absolutely no idea what’s going on!

We’ll have another look at some point, but it’s really odd. I think it may be something to do with edgetables, but couldn’t track it down.

Well, as I mentioned above - my messing around with it points to something with the stenciling. Clearing the entire viewport instead of subregions does rid of the problem.

I don’t know if that’s a viable solution, we would have to A/B test and measure on low powered devices like mobile.

No, we did show that that wasn’t the problem, and obviously just constantly repainting the entire window isn’t a realistic solution.

It seemed to be an artefact of an error when intersecting edge-tables which only really happens when you’re using a non-rectangular clip region. It’s nothing to do with GL itself, but just becomes visible because of the way GL uses a buffer to draw into.

Sorry, where was this shown? Feeling like I missed something here when trying to learn more about how this stuff works.

But yeah, I now see how constantly repainting and clearing the viewport only masks the original problem.

I just meant that while we were investigating, we figured that out - no time to explain all the details here.

I see now. Alright, all good.

I’m seeing the same issue as you’re describing. Did you find a fix for it?

No, I didn’t find a fix but the problem disappeared somehow. I can’t remember anymore when it was exactly and if it was connected to a driver update. But since I observed the problem only with integrated Intel GPUs I still think that my problems were caused by the driver.