```Error: Could not find or load main class org.gr...

# compose-ios

[markturnip]

Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
Caused by: java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain

[markturnip]

think you just need to run gradle wrapper
I don't have gradle installed on my machine atm

[markturnip]

just get you to commit the gradle-wrapper.jar and I can have another little poke around

[markturnip]

right found another wrapper and it got it building

[markturnip]

interestingly even if using preferredFramesPerSecond to just one frame a second, it's reaches EXC_BAD_ACCESS by 11 frames:

setView(GLKView().apply {
    paused = true
    preferredFramesPerSecond = 1

[markturnip]

did try look look for a way to synchronize with the Skia rendering pipeline by manually triggering setNeedsDisplay

DisposableEffect(frameCount) {
        // Trigger redraw on the GLKView manually by using the stored ViewController reference
        viewController.view?.let { glkView ->
            if (glkView is GLKView) {
                glkView.setNeedsDisplay()
            }
        }
        onDispose { }
    }

frame count did get up to 595 before faulting again

[Jeffrey Bush]

Sorry for the delayed response. Thanks for looking into it. Interesting idea to try one frame per second and it still dies after ~10 seconds. I didn't think about syncing that way with the rendering pipeline, very interesting!

[Jeffrey Bush]

I have been wondering if it is due to this: "Your drawing method should only modify the contents of the framebuffer object. Never attempt to read the pixel information from the underlying framebuffer object, modify or dispose of the framebuffer object, or read its other properties by calling OpenGL ES functions. Instead, rely on the properties and methods provided by the GLKView class."

[Jeffrey Bush]

That does refer to only the drawing method, but it could indicate that it has assumptions about the state of the framebuffer and that Skia is messing with its assumptions.

[Jeffrey Bush]

I will hopefully get a chance to play around with Metal-based GLKView in the next few weeks.

[markturnip]

no worried, curious to follow

[markturnip]

didn't see the OpenGL error you mentioned, but suppose you could remove the functions it's complaining about and still have the render ticking over to see if it still occurs

[markturnip]

not looked into how to intercept the skia render loop, but thought might share this article if of interest:
https://medium.com/@mmartosdev/pushing-the-boundaries-of-compose-multiplatform-with-agsl-shaders-d6d47380ba8a

[Jeffrey Bush]

I know it has been a really long time, but I finally had a chance to come back around to this. I found the issue: the delegate fields of the GLKView and GLKViewController classes is marked as unowned(unsafe) which means the reference count is not incremented when assigned and thus if there are no other references to it, the delegate is marked for deletion during the next garbage collection cycle. I found this out due to trying to write some of the code in Swift/Obj-C itself and it gave me the warning there that the object would be immediately deallocated. The unowned(unsafe) marker is like a weak reference (which is another annotation possible in Objective-C) but even worse since it doesn't even know that is has been deallocated.

[Jeffrey Bush]

Additionally, I have experimented and I have been able to use the deprecated GLKView along with the MetalANGLE version which is actually uses Metal internal but makes it act like OpenGL.

[markturnip]

Glad to hear you figured it out; thanks for sharing back!