I will let someone else confirm there is no explicit toggle such as processing’s noLoop() in OF, but your test reveals a form of problem with the renderer, perhaps some caching or buffering issue. Like you I get nothing with ofGetFrameNum() == 0 but ofGetFrameNum() == 3 creates flickering effect of the frame (here on macOS13.1 at least). You are invited to report that as an issue: Issues · openframeworks/openFrameworks · GitHub
But notwithstanding the above, depending on your end goal perhaps writing to an FBO once would be a better approach? They are allocated in dedicated VRAM, whereas the framebuffer/window is being tickled by the App, openGL/glfw, the OS…
Hi @08_objekt , I agree with burton’s comments. I don’t think OF has an equivalent to Processing’s noLoop(). It might be helpful if you post a bit more about what you’d like to do. OF is designed to run an application with an update/draw cycle.
I think there is a slight delay in between when an app starts the update/draw cycle, and when the window is ready for rendering. I ran your code on a m1 Mac and needed 3+ frames before it rendered something. The number of frames might be higher for other systems, or lower for lower frame rates.
I had a flickering too, which seems to be related to the double buffering for the window. This stopped the flicker for me:
// in main.cpp
settings.doubleBuffering = false;
You might also have a look at rendering once into an ofFbo, and then drawing it each cycle. An ofFbo will retain the previous rendering unless ofClear() is called. So something like this:
// in ofApp.h
// in ofApp::setup()
fbo.allocate(ofGetWidth(), ofGetHeight(), GL_RGBA);
// draw something
// in ofApp::draw()