processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.65k stars 3.32k forks source link

Allow frame rate to go past monitor refresh rate #2877

Closed clay53 closed 6 years ago

clay53 commented 6 years ago

Nature of issue?

Most appropriate sub-area of p5.js?

Which platform were you using when you encountered this?

Details about the bug:

Feature enhancement details: Allow frame rates to go higher than the monitor's refresh rate. I think this is the problem because it is stated in issue #2372. In the old issue, it is said that you don't need to do this so it doesn't matter, but otherwise, my sketch would have an exceptionally large loop and the browser stops responding until it is finished. Also, it looks cool. Video of the problem: https://drive.google.com/file/d/1IXIWO-zYlG4n9B1v2Ufj2G1nJiOL4_iw/view?usp=sharing

limzykenneth commented 6 years ago

The Google Drive link you shared is not shared publicly so I cannot see it. Can you briefly describe your use case?

clay53 commented 6 years ago

@limzykenneth Sorry, accidentally used my org acc - didn't know it was viewable to people in the org only - I'll upload it once I get back on my PC. I was developing a program to make a program to make an image out of other images - without just overlaying the images with a different color - however, looping through all the pixels on an image and drawing a image for each pixel (depending on settings) will cause the browser to be unresponsive for a long time, until it completes. Edit: video: https://drive.google.com/file/d/1Cv1IQlfQgkSz49D7ITYo0HO_orzh-8Nj/view?usp=sharing

meiamsome commented 6 years ago

Yeah, with the underlying requestAnimationFrame you are locked into whatever the browser gives you (not this is usually no higher than the monitor refresh rate, but it can be higher).

You can take control of the loop yourself with something along the lines of:

function setup() {
  // rest of setup
  noLoop();
}

function draw() {
  setTimeout(redraw, 10); // where 10 is the minimum time between frames in ms
  // rest of draw
}

or:

function setup() {
  // rest of setup
  noLoop();
  setInterval(redraw, 10); // where 10 is the minimum time between frames in ms
}

But you are not likely to have a stable FPS with this and you might see some browsers capping you harder. There are other performance issues with this, but yes - it is possible to go faster (I was able to achieve ~250 fps on my pc/browser with this by setting the minimum interval to 0ms, but with more complex draws this will inevitably slow down)

clay53 commented 6 years ago

@meiamsome Thank You! This solution works for me. However, do you know if this would be possible to enable/disable during runtime? If not then that's fine it doesn't make that huge of a difference.

meiamsome commented 6 years ago

@clay53 you could try something like:

var customLoop = false;
function enableCustomLoop() {
  noLoop();
  customLoop = true;
}
function disableCustomLoop() {
  loop();
  customLoop = false;
}

function draw() {
  if(customLoop) {
    setTimeout(redraw, 10); // where 10 is the minimum time between frames in ms
  }
  // rest of draw
}
Spongman commented 6 years ago

does the browser ever present the page any quicker than the requestAnimationFrame frequency? if not, it might just be easier to put a for loop inside the draw function.

function draw() {
  for (var i = 200 / frameRate(); i --> 0 ;) {
    myDraw();
  }
}
clay53 commented 6 years ago

@meiamsome Thanks! I'll try to implement this concept.

clay53 commented 6 years ago

@Spongman You actually anger me.

meiamsome commented 6 years ago

@Spongman I think that's browser dependant... I would be very surprised if they did allow you to render faster than that, but you can definitely simulate more frames, if, for example, you are trying to record the canvas