Further information: the error appears in a response to changing the 'scale' which is how I magnify the field of view. In response to a key stroke 'Command" plus '+' the program changes the orthographic scale. The 'scale' parameter decreases until a [consistently] small value - then the problem appears.

The error appears also in the perspective view, with successive narrowing of the field of view occurring successfully until a small value has been reached. 2022-07-22 11:06:26.417539+1000 ######[14050:1284516] camera.fieldOfView   3.0003E+00

In orthographic view the problem begins once the scale is less than a small value, and always after the eighth time the scale has been decreased: ... 8.0000E-01 ... 6.4000E-01 ... 5.1200E-01 ... 4.0960E-01 ... 3.2768E-01 ... 2.6214E-01 2022-07-22 11:15:58.819794+1000 Pplates[14114:1294072] camera.orthographicScale = scale   2.0972E-01 2022-07-22 11:16:12.877800+1000 Pplates[14114:1294072] camera.orthographicScale = scale   1.6777E-01

Thank you for your reply gchiste. Actually, strangely, it is the other way around. Less and less geometry is visible. The issue seems almost like one is getting too close to the object. The problem does not happen with the intel version, the code has been stable for quite a while now. It is only now that I have switched to developing on a MacStudio that the problem has appeared, so I assume this is the cause. Hence my guess that it has something to do with unified memory and the way it is handled. So I interpreted the "memoryless render target' as something to do with unified memory. If you can point to where I can read more information that would be helpful. I do use a collection of MTLbuffers that I earlier 'blitted' to the GPU [which seems a needless operation perhaps when unified memory is involved?]. But there is no issue that I can see. The only thing that changes is 'orthographicScale' [or fieldOfView when using perspective view] so I am perplexed.

First I would like to thank gchiste for the quality (and patience) of his technical support. Second let me outline just what went wrong. Indeed I had one SCNNode set with the geodesic = YES and a segment count of 1024. This caused the issue as gchiste described. Other nodes in the mesh were decorated with spheres, geodesic = NO, and segment count 8. Even so these caused the geometry to become increasingly dense. Each sphere had to have its own geometry, since otherwise what was done to one would happen to all. Now, instead, unless a node is selected, no sphere is shown. There were other things, related to my inexperience, paraphrased/modified/quoted from gchiste : the frame capture option for the GPU trace is no longer a camera icon but an italic M in the debugger menu. It is useful in allowing the number of vertices in any scene to be examined. When you open the GPU trace, select the Profile option, then go to the Performance tab, select “Counters”, then select “Vertices”. This will show you the number of vertices for each render command in that frame. "once you have zoomed in far enough ... (the) ... automatic Hidden Surface Removal (HSR) performed on the GPU ... keeps the GPU from overdrawing pixels that won’t have any effect on the final render (for more info about HSR and the TBDR architecture ... watch this video: https://developer.apple.com/videos/play/wwdc2020/10602/) recommend you ... enable the SCNDebugOptionRenderAsWireframe option on your SCNView. Again thanks gchiste.

Advice on the net is to create a cut down version prior to creating a TSI. Easier said than done, given that this is a large program. And somehow one is supposed to reduce the problem to <250 lines which seems utterly infeasible in this case. Nevertheless, some days and many hours later, the program is vastly reduced, but still there are >150 files to comb through. The useful outcome of this work however is that I can characterise the 'phenomonology' that surrounds the appearance of these message strings. Sometimes after a rebuild, the cut down program must be launched sequentially several times before the messages begin once again to appear. I suppose therefore that somewhere in the program worker threads are launched that SceneKit cannot manage properly, or that there is something I am doing that prepares the ground for thread conflict. I do not know.

The issue seems of wider impact than just with text fields. DTS Engineer could you provide some clues so we can try to work around the problem while Apple tracks it down?

Hello Greg, Thanks. I resubmitted a bug report, this time on a thread that included SceneKit.