From then on (but within the same method so that the openGLContext is still active and current) I can save the image to disk, or manipulate it in other ways really nicely on MacOS.
With iOS however I get fatal errors:
GL_INVALID_ENUM at /Users/jeffr/git/submodules/tracktion_engine/modules/juce/modules/juce_opengl/opengl/juce_OpenGLFrameBuffer.cpp : 125
Something is passing back a number of which there is no corresponding enum value.
I have tried other ways of manipulating the data captured via makeCurrentRenderingTarget, such as doing a std::memcpy. Even snapshotImage.getPixelAt(int pixelX, int pixelY). Everything I have tried thus far will trigger a crash.
My guess is that the memory for openGL on iOS is protected somehow, perhaps because of threading?
Does anyone have any idea/advice on how I might be able to get past this please?
It looks like glBindFramebuffer should only generate GL_INVALID_ENUM if the first argument is not GL_((READ|DRAW)_)?FRAMEBUFFER. It’s more likely that the error is triggered elsewhere, and we only find out about it here.
You could try using glDebugMessageCallback to register a function that will be called on error, and stick a breakpoint in that function to find out exactly where the error originates.
…it will error. Maybe it’s cos without that line the rest just gets compiled out for not being used. Adding a breakpoint and stepping in and over I find that the this line:
const BitmapData srcData (*this, x, y, 1, 1);
…in Colour Image::getPixelAt of juce_image.cpp is where I get the invalid enum.
If I resume execution I ultimately crash out with a SIGTRAP here in __mutex.base.
condition_variable::wait(unique_lock<mutex>& __lk, _Predicate __pred)
Is that a clue? That a mutex was involved?
I’m happy to upload a simple test case of this which is based on the OpenGL tutorial from the JUCE website. Basically my test case is that, with the teapot embedded as binary data, and my above code put into the render() method.
Thanks for that! I was really hopeful that that might work, but alas I ended up with the same mutex_base error, even with all the glFinish() statements (to be clear I did use what you kindly provided verbatim, as well as reordering stuff.
I also tried this where I add a snapshotImage.createCopy() to try and force an explicit copy of the data out into a memberVariable with class scope/lifetime (rather than function scope/lifetime).
Oddly enough the crash doesn’t happen on the createCopy() but with the getPixel, which is odd as I’m actually running it on a totally different image!
It’s like whenever I try to touch the image data it throws a hissy fit. I am still wondering if iOS is multithreading the rendering and write to image data, and that maybe its tricky to get to that one moment when the image is complete and acailable for access (please pardon my lack of understanding).
Surely it must still be possible though right? Is there a more powerful version of glFinish() that really does grind everything to a halt so you can sync things safely?