Repainting glitches on Mac OS 10.10

Is anyone else seeing repainting glitches on OS 10.10?  I built a build of the app in the movie shown below with Xcode 6 against the OSX 10.9 sdk, and there are random flashes when various parts of the UI are repainted when it's running on OS 10.10.

https://dl.dropboxusercontent.com/u/1383432/H9%20Control%20OSX%20Display%20Glitches.mov

I'm not saying this is a Juce problem. I don't know what's causing it at this point. I'm just asking if anyone has seen any similar behavior in their apps.  We're using Juce 2.0.37 in this build.

I'm going to try building against the 10.10 sdk and see if that takes care of the problem. The reason I didn't do this in the first place was b/c of the build problems one runs into doing this described in this thread: http://www.juce.com/forum/topic/build-problem-using-xcode-6

Hi symfonysid, have you solved your repainting issues ?

I'm also having these flashes where the background color of the window appears during some repaints, although quite hard to reproduce. I can't get the juce demo to show them , for example. But with a simple image viewer that gets repainted when the mouse move, I have these random flickers. I'm building with the latest juce version, with the 10.10 sdk (does not change anything). This issue happens only on yosemite.

can confirm i am too getting these flashes 

 

im using 10.6 SDK - and its only aparent in Yosemite

the latest Yosemite update seems to reduce the occurance of the flashing to an acceptable level

I think we're experiencing the same issue. I created a new topic just now before I saw this. Our users are still reporting it on Yosemite 10.10.2 and we're building with the 10.10 SDK. Has anyone found a solution? 

http://www.juce.com/forum/topic/graphical-flicker-when-moving-slider

I am experiencing the same problem on Yosemite. I'm using AULab for developing a plugin and am on a MacBookPro Retina using the intel GPU. I think there is no acceptable level of flashes. I'm still trying to find a reliable way to reproduce the problem. Often things are fine, but sometimes things appear to go into "flicker mode" and then the flickers happen quite often. Initially I thought it happens in case a control is marked dirty for repainting with repaint() while it is still drawing and I do have some controls that take quite some time to redraw. However the problem also happen on simple knobs and sliders for me. I'll now update the machine to 10.10.3 to see whether that helps - however as my JUCE based plugin is the only application of the system that is flickering, I doubt OS updates are going to help.

See my reply on the thread that's linked above.

Basically, on OSX if your paint routine takes too long, then the OS will flush the not-yet-finished graphics to the screen while it waits for you to finish. You say you have some controls that "take some time to run" so I assume that's your problem - you need to keep your paint routines fast!

Well... there is just stuff that takes some time to draw. I'm talking about analyzer displays and similar stuff. Of course I try to do things as quickly as possible. I don't think what's happening is what you described in the other thread.

I tried replicating the issue now that I know I'm not the only one getting it. Since I posted I had it happen inside the Juce Demo Plugin with a standard slider. But only once and ever since I reinstalled snapz pro to capture a movie it hasn't happened again.

AFAIK OSX is usually very good in avoiding flicker even if drawing takes long. So I think something else is going on and I'll keep trying to replicate the problem. For me, once the flickering starts, it happens quite often on all sorts of controls until the app is stopped, it's just more annoying on my larger displays than on small knobs. Afterwards it might not happen for hours/days which made me think multiple times I fixed the problem in my code. And then it suddenly happens again. 

Anyway, the screen capture utility will now keep running and I'll try to make a movie of the Juce Demo Plugin flickering when hosted in AULab to prove it's not my code that's causing the issue ;).

 

Hmm trying to record that movie I got the flicker inside the XCode GUI! And on the other hand while I tried to capture the movie inside my plugin I saw it happen, but the recorded movie was fine! So maybe it's some graphics driver OS issue. I'll now finally update to 10.10.3 and see if things are better with that.

 

I updated to 10.10.3 and haven't seen the flicker since. I also read on the web on similar problems with all sorts of apps on the 15'' Mac Book Pro Retina. A "fix" appears to be to force the discrete GPU to always on, so it probably is (hopefully was) a problem with the GPU switching and the graphics drivers on Yosemite.

Should I see flicker again, I'll be sure to post :P.

I still see those flickers on osx 10.10.3 , unfortunately. And it is not related to gpu switching since I'm getting it on macs with a single gpu. Maybe it is related to the GPU brand ? My macs all have ati radeon graphics cards.

A few weeks later here are my current results. I still see flickering occasionally on 10.10.3. I see a lot more flickering in debug builds, but it probably all comes down to performance. I optimized some drawing in my plugin and made as many components opaque as possible and that has helped a bit. But I still believe there is a bug/conflict with Yosemite somewhere in JUCE because most of the time things are fine and sometimes there is (black) flickering. And I see no logical reason why taking some more time to draw something should lead to flicker.

In another thread people switched to using an OpenGL context and that appears to solve the problem. For me this is not an option because that way OS X text rendering is lost.

And I see no logical reason why taking some more time to draw something should lead to flicker.

I already explained this several times on other threads, but here it is again:

On OSX, when a UIView is repainting and its drawRect: method takes too long to complete, then under some circumstances the half-finished contents of the graphics context can get flushed to the screen while it's still waiting for you to finish. Maybe other processes are contending for the GPU memory or something, or maybe it's deliberate so that if people are doing really long drawing routines, then the user won't be left with nothing happening for seconds at a time. I don't know. But obviously it'll look like a flicker.

But if this is what you're seeing, then other than writing a faster paint routine, then there's not really any way it could be avoided.

Here is a small app that produces tons of flicker on Yosemite (and only on yosemite) for me:

 

#include "../JuceLibraryCode/JuceHeader.h"
int width=800;

class FlickerComponent : public Component, public Timer
{
    Image img;
    int y;
public:
    FlickerComponent() {
        setOpaque(true);
        img = Image(Image::ARGB, width, width, true);
        Graphics g(img);
        g.setColour(Colours::yellow);
        g.fillCheckerBoard(Rectangle<int>(0, 0, img.getWidth(), img.getHeight()), 10, 10, Colours::white, Colour(0xffB0B0B0));
        
        setSize(width, width);
        y = 0;
        startTimer(20);
    }
    void paint(Graphics &g) {
        double t0 = Time::getMillisecondCounterHiRes();
        g.setColour(Colours::black); g.fillAll();
        g.fillCheckerBoard(Rectangle<int>(0, 0, img.getWidth(), img.getHeight()), 10, 10, Colours::yellow, Colour(0xffffA000));
        g.drawImageAt(img, 0, 0);
        g.setColour(Colours::green); g.drawHorizontalLine((y++)%getHeight(), 0, getWidth());
        double t1 = Time::getMillisecondCounterHiRes();
        DBG("t=" << t1-t0 << "ms");
    }
    void timerCallback() { repaint(); }
};

class Window :
public DocumentWindow
{
    FlickerComponent *c;
public:
    Window() :
    DocumentWindow("TEST JUCE FLICKER", Colours::blue, DocumentWindow::closeButton) {
        setContentOwned(c = new FlickerComponent(), true);
        centreWithSize(getWidth(), getHeight());
    }
    void closeButtonPressed() {
        JUCEApplication::quit();
    }
};


class App :
public JUCEApplication
{
    Window *w;
public:
    App() {}
    const String getApplicationName() { return "test_juce"; }
    const String getApplicationVersion() { return "1.0"; }
    void initialise(const String &) {
        w = new Window;
        w->setOpaque(true);
        w->setVisible(true);
    }
    void shutdown() { delete(w); }
};

START_JUCE_APPLICATION(App)



I'm still wondering if there could be a magical coregraphics or whatever switch that would disable that stupid "flush in the middle of drawrect" thing that happens with yosemite. But I can't find any hint of such an issue with yosemite on google.

No flicker at all on my machine! (latest 10.10.3)

Neither on a normal monitor or retina display.

Yes I saw this explanation on other threads, but things don't add up for me. What I am seeing is black rectangles the size of single components for 1 frame. Most of the time this does never happen, but occasionally it starts happening a lot. If it was unfinished drawing, I doubt I would see black rects if it was just unfinished drawing as the first step usually is to fill the rect with a non-black background colour and that certainly can't take long. 

I'm also not fully convinced it does happen more often for components that take longer to draw. It might just be an illusion as it's much more visible on large components that naturally take longer to draw. In the meantime I have seen it occasionally on very small components as well that certainly don't take much time to draw. 

Additionally for research I once wrote a JUCE app that took about 1 sec to draw a component, and I've not seen unfinished drawing with that.

However I believe I've seen it once on the XCode GUI! So it might be a totally JUCE-unrelated bug in OSX, but it appears to happen more often in JUCE-based apps than in regular apps.

I will now try the demo code submitted below and I will try an openglcontext just for comparison.

 

I see a lot of flicker with that example. I see full window black/yellow frames. It gets much worse if the window is in the background. And a debug build also makes it worse. And hurray. I've finally been able to record it using Snapz Pro! I get it both in retina and non-retina resolutions on Macbook Pro Retina 2012 running 10.10.2. Both with integrated and discrete GPUs. Of course this looks much worse than what I see in my plugins.

I uploaded the largish mov file (18.5 mb) to my server so you can have a look:

http://www.pflugshaupt.com/FlickerTestScreenSnapz001.mov

 

 

 

Using an OpenGLContext with that same example code does totally solve the problem. 

So in order to find the problem I rewrote the flicker example without JUCE. I created a Cocoa Application and made it draw checkerboards the same way JUCE does and guess what..! I got it to flicker as well!

So it appears to be an unsolved OS (Yosemite) problem in Quartz drawing and I wasn't dreaming when I saw XCode's GUI flicker. The crazy thing is that with the Cocoa code I had to try much much harder to get the same amount of flicker that is easily obtainable with JUCE. So maybe something in JUCE just makes this problem appear more often.

And maybe it is limited to the MacBookPro Retina 15 model. Unfortunately I do not have any other mac to try with.

It's not only retina mbp, I'm getting these flickers on a mac pro 2008 and imac 2011. I guess the timing is important, the 20 ms timer of the example for tuned to maximise flickering on my old mac pro, larger values, and ever lower values, produced less flickering