For those who don't know about framerate..a little demo

examples
#21

i notice that a displaylink process was the 2nd or 3rd highest in my cpu usage list.
so i uninstalled it and it does look much better.
still a few hick ups here and there.

i also tried adding couts after every major step for update and draw. like this

  
  
    //4  
    cout<<" "<<ofGetElapsedTimeMicros() - ddur<<"\t";  
    ddur = ofGetElapsedTimeMicros();  
    dstep++;

here the full code: http://pastebin.com/J5VeAEvf
with these results.
seems it takes about 17455 between the end of update and a new beginning of update.

strange is that draw is always happening after update.
i thought update happens more often then draw. but i guess i was wrong.

upat 17455 2 29 81 155 8 draw 17487 63 218 3 2
upat 15697 2 22 82 210 10 draw 15758 79 268 4 2
upat 16780 1 23 83 156 8 draw 16681 62 178 2 2
upat 16019 1 29 81 156 8 draw 16060 63 176 3 2
upat 15526 1 20 73 172 7 draw 15555 57 152 2 1
upat 17606 2 24 84 157 8 draw 17679 62 212 4 3
upat 15701 1 24 74 134 7 draw 15621 55 159 2 1
upat 17117 2 22 97 173 8 draw 17210 63 223 3 2
upat 15502 1 20 86 158 10 draw 15508 63 206 3 2
upat 17276 1 18 65 118 6 draw 17188 49 136 2 1
upat 15874 2 25 79 156 8 draw 15976 78 221 3 2
upat 16256 1 21 75 137 7 draw 16186 56 195 2 2
upat 17011 1 24 84 159 9 draw 17042 62 225 3 2
upat 15248 1 19 67 150 6 draw 15192 51 136 2 1
upat 17409 2 27 99 270 11 draw 17671 66 188 2 2
upat 15330 1 20 74 176 7 draw 15355 57 203 3 2
upat 16986 1 18 64 106 6 draw 16898 47 123 2 2
upat 16334 1 22 81 158 8 draw 16453 62 187 2 2
upat 15544 1 22 72 177 8 draw 15570 55 160 3 2
upat 17560 1 26 83 252 12 draw 17749 73 337 4 3
upat 15499 1 21 76 137 13 draw 15301 50 137 2 2
upat 17370 1 23 84 189 9 draw 17493 63 188 4 26

also seems like my Intel HD Graphics 4000 512 MB is creating more jitter then the older ADM radeon HD 6750M 512M

#22

i know this is an old thread. but i still see the same behaviour.

i guess the time one update() loop takes is not constant. so if you try to move an image at a constant real life speed (same distance in same amount of time) then the image needs to be jump forward to catch up.

#23

What I think for this case:

There is 2 calculation points:

  1. The point when OF calculates the lastframerate.
  2. The point when you calculate beltPos +=…

OF doesnt calculate it when you call ofGetLastFrameTime() but it calculates it in ofNotifyUpdate(). Then something does probably happen. Then you get the frametime.

Everything happening between this 2 points may affect the real timedifference you need. And it may cause the inconstancy.

What I would suggest you is, calculating the time difference yourself just before the beltPos +=… line.

time2 = ofGetSystemTimeMicros();
timediff = time2 - time1;
time1 = time2;
beltPos += timediff * 0.000001 * 200;

ps. Of course you need to calculate the ever first time1 in the beginning of the animation.

#24

thanks for taking the time to help me.

i will give it a try.

but wouldn’t it make sense that if the app is busy with something else (in my case loading in an image) that other processes (like draw an image in the right position) stop for a moment and then resume which looks like a jump?

in my case i am using 2 hd projections; i.e. lots of pixels to write to.