# Bug: Deadlock in CoreGraphicsMetalLayerRenderer? **URL:** \ **Category:** MacOSX and iOS\ **Created:** [November 14, 2022, 3:23pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740 "2022-11-14T15:23:54Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 14, 2022, 3:23pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/1 "2022-11-14T15:23:54Z")
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](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/f/f23739af092cefe1fefe8e4ac072ccf31855aefd.jpeg) The last function in the trace that is accessible is `CoreGraphicsMetalLayerRenderer::drawRectangleList` ![trace2](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/7/73721bbe273a707442b0855a5a4050065e3cacef.jpeg) 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 ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 23, 2022, 3:11pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/2 "2022-11-23T15:11:38Z")
Anybody? ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [January 19, 2023, 8:03pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/3 "2023-01-19T20:03:37Z")
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. ---
**Author:** ![Verbonaut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/verbonaut/32/11824_2.png) [@Verbonaut](https://forum.juce.com/u/Verbonaut)\ **Post date:** [January 19, 2023, 11:06pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/4 "2023-01-19T23:06:37Z")
Does this happen in a simple test app that the Juce team could be given to evaluate? ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [January 20, 2023, 12:57am UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/5 "2023-01-20T00:57:01Z")
> [@Verbonaut](#): > > Does this happen in a simple test app that the Juce team could be given to evaluate? 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… ---
**Author:** ![rebbur](https://avatars.discourse-cdn.com/v4/letter/r/ecae2f/32.png) [@rebbur](https://forum.juce.com/u/rebbur)\ **Post date:** [January 20, 2023, 9:07am UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/6 "2023-01-20T09:07:08Z")
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. ```auto [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. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [January 20, 2023, 3:36pm UTC](https://forum.juce.com/t/bug-deadlock-in-coregraphicsmetallayerrenderer/53740/7 "2023-01-20T15:36:46Z")
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.