Bug: Deadlock in CoreGraphicsMetalLayerRenderer?

MacOSX and iOS
1

When I leave my GUI app running overnight, doing nothing, relatively often the next morning I find “Application Not Responding”, and doing a break in the debugger shows me this exact same trace always.

It appears that I am getting stuck in some sort of loop (I guess you call this a deadlock or race condition)?

trace3
trace32120×2504 377 KB

The last function in the trace that is accessible is CoreGraphicsMetalLayerRenderer::drawRectangleList

trace2
trace22120×1470 371 KB

I am assuming this is because I am using JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS=1 ?

Is this potentially a JUCE bug, or could there be something in my code that is causing this? Any suggestions on how to find it?

MacOS, Intel, JUCE 7.0.2
Mojave 10.14.6, Xcode 10.3

2

Anybody?

3

This is still a problem. When I compile two different versions of the app, one using Metal:

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS=1

and the other not:

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS=0

…and leave them running overnight (but doing nothing other than blinking an LED), the one using Metal gets in this deadlock while the other one does not.

This is now with JUCE 7.0.3.

4

Does this happen in a simple test app that the Juce team could be given to evaluate?

5

I’m afraid not, because the blinking LED is part of an overall complex event-processing scheduler. I’m not necessarily blaming it on JUCE, although it could be that - it seems a little suspect that it happens with the CoreGraphicsMetalLayerRenderer and not when compiled without it…

I was also hoping for some advice on how to find the cause of a deadlock…

6

The JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS 0 define does not mean its not using Metal. It already always does when these calls are made, see NSViewComponentPeer constructor.

                [view setWantsLayer: YES];
                [[view layer] setDrawsAsynchronously: YES];

When drawing is asynchronous, a background thread is used by the os to do the drawing and it uses Metal for this. It is already really fast, the multiple paint call system is a nice optimisation but its not fool proof at all atm. So i would rather rely on the os doing this and stay away from the multiple paint calls atm.

7

I have many meters and LEDs updating on a large window. When a tiny led in the upper left blinks at the same time as a tiny led in the bottom right, the whole window is forced to repaint - a gigantic area that is completely unnecessary. This causes a large performance hit. That’s why I want to use this “feature”.

Maybe you’re right about it using metal all the time regardless of this #define. I don’t know too much about it. I only know that with

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS 1

…I get a significant performance boost on my redrawing… but it eventually deadlocks, and with

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS 0

… it never deadlocks but the redrawing hit is large.