ofApp::draw sometimes skipping a draw on Linux desktop (Ubuntu)?

I’m using Ubuntu 14.04.5 LTS, and I was doing an app in OF rev. 16eca45a1d45a from git. In this app, I have a small FPS display in ofApp::draw(), and it was working great.

Then I tried recompiling the app with tag 0.9.3, and suddenly I could notice the FPS display sometimes randomly “freezing” when I click on the app GUI; it looks somewhat like this:

Notice how at a certain point, the FPS stops changing and sort of “freezes”. Then I tried recompiling with OF tag 0.9.0, same thing. Finally I went back to 16eca45a1d45a, and again same thing, and now I can’t get rid of this behavior (the above gif was taken with a OF 16eca45a1d45a based build)

The code for that part is something like in this minimal example:


#pragma once

#include "ofMain.h"

class ofApp : public ofBaseApp{

    void setup();
    void update();
    void draw();

    void mousePressed(int x, int y, int button);


#include "ofApp.h"

void ofApp::setup(){

void ofApp::update(){

void ofApp::draw(){

  // ... some other drawing in orig app here ... then:

  ofDrawBitmapString( ofToString((ofGetFrameNum() % 2 == 0)?"-":"|"), ofVec2f(0, 32) );

  ofDrawRectangle(ofPoint(0,0), 100, 20);
  ofDrawBitmapString( "FPS: " + ofToString(ofGetFrameRate()), ofVec2f(0, 16));

  ofLogNotice() << "d";

void ofApp::mousePressed(int x, int y, int button){
  // simulate "doing something":
  float o = 0;
  for(int i = 0; i < 10000000; i++) { o += ofRandom(i); }
  ofLogNotice() << "mousePressed " << o;

Unfortunately, this minimal example does not reproduce the problem, but it shows the actual code for the FPS drawing part.

The strange thing is, even if this freeze happens - the ofApp::draw() still runs, which is evidenced by the ofLogNotice() << "d"; being output to terminal continuously even when the “freeze” happens in the GUI display (furthermore, note that even when the freeze happens, the framerate is still shown around 60 fps, which means that draw()s should be running in the background).

It’s as if just the particular draw commands for the FPS are skipped, resulting with a frozen appearance, while the rest of the OF engine actually works ?!

Could this be a problem with X window drawing events or something? The only thing I remember changing recently with the graphics, is that Ubuntu 14.04.5 LTS bumped to a new kernel (4.4.0-34-generic), after which I noticed that lightdm-gtk-greeter from MATE desktop flashes when first being shown at start after reboot (and this occurs now in both 4.4.0-34-generic and the previous 3.19.0-66-generic, whereas it didn’t occur previously when there was only 3.* series Linux kernel).

Has anyone else experienced something like this? And would anyone know how to get back to the proper frame drawing behavior that I used to experience previously for my Linux desktop builds?

calculating 10M random numbers like you are doing on mousePressed can take a while so that might just be it. depending on what you are doing it might be taking some time to finish freezing the app meanwhile. be sure to also compile in release so the application is run as fast as possible

1 Like

Many thanks for the response @arturo,

Sorry, I should have been clearer that I just put that in as a stand in for my real app (and even that example does not really reproduce the problem); however, the gif is taken with my real app - and there it changes some animations in the part of the screen not captured.

But the weird thing is, when I click as shown in the gif, I actually toggle between two states, so while there are indeed increased demands at those times, they do not change, so it is weird why this “freeze” kicks in randomly. I’ve also noticed at times complete freeze of FPS, and then I move the mouse, slowly (like each half second) the FPS display changes, then when I stop moving the mouse, it freezes again (all the while, reacting on clicks and dumping messages to stdout).

Anyways, I remembered to run some earlier builds that I definitely haven’t recompiled since I started seeing this, and now they also show this behavior! So it looks like OF isn’t the culprit, nor the build process, but probably some other recent update to Ubuntu… (or some program which I may have installed).

Thanks, I completely forgot about this. But I found some earlier builds which were release, and they also seem to have started displaying this problem now :frowning:

If I learn something more about this, I’ll post back…

Just wanted to note that I tested a build of the same code, same computer, same OS - except it is Ubuntu 14.04.5 64 bit, and that one does not show this freezing! So, for me only Ubuntu 14.04.5 32-bit shows this freezing/skipped draw problem. Not sure why that would happen, though…

Just had an opportunity to test this again; I started suspecting the drivers, which currently on my system seems to be this MESA:

$ uname -a
Linux myPC 4.4.0-47-generic #68~14.04.1-Ubuntu SMP Wed Oct 26 19:41:45 UTC 2016 i686 i686 i686 GNU/Linux
$ cat /etc/issue
Ubuntu 14.04.5 LTS \n \l
$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30

So I tried upgrading as per http://askubuntu.com/questions/501560/how-to-update-opengl-driver-on-ubuntu-14-04-lts - however, I couldn’t upgrade, as the ppa:oibaf/graphics-drivers doesn’t carry any versions for 14.04 anymore…

However, the text for this repository also had some suggestions for using environment variables - and when I tried:

LIBGL_ALWAYS_SOFTWARE=1 openFrameworks/apps/myApps/myTestApp/bin/myTestApp_debug

… finally, the FPS was stable again! So it’s probably some problem with MESA driver and/or hardware acceleration… For reference, this is what my graphics card seems to be:

$ sudo lshw -class display
       description: VGA compatible controller
       product: 3rd Gen Core processor Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:27 memory:f7800000-f7bfffff memory:e0000000-efffffff ioport:f000(size=64)

according to docs that seems to switch the drivers to a software emulation which would be pretty slow for anything slightly complex.

can you check if you have the problem too using the nightly builds instead of 0.9.x?