help in p5.js performance improvement on mobile devices

Answers

• faytom

  June 2015 edited June 2015

  hey there i guess i have worked it out. So here is my solution,

  1. go to p5.js on line 1627 and 1628, and comment there two line out like the following: //this.elt.style.width = w + 'px'; //this.elt.style.height = h + 'px';

  2. within the setup of your sketch.js, set the parameter width and height in createCanvas to a mederate value which is smaller than your mobile resultion. say 400X600

  3. attach a css style sheet to your html, specify the canvas size to width:100% height:100%

  4. and there you go, run your script on your mobile devices and it just works like a charm

  can anyone explain to me why this can solve the laggy issue of running p5.js on mobile devices???
• GoToLoop

  June 2015 edited June 2015

  Can anyone explain to me why this can solve the laggy issue of running p5.js on mobile devices???

  Of course in general, the smaller the canvas, the better the performance! :P

  In my few experiences, p5.js was very slow overall too...
  But that's expected since it's still in beta and didn't reach stable v1.0 yet! :-\"

  I've adapted a game in Khan's pjs for "Java Mode" called "Hoppy Beaver" from: http://www.KhanAcademy.org/computing/computer-programming/programming-games-visualizations/side-scroller/a/scoring-and-winning

  Then run that in "JavaScript Mode" (pjs framework) too w/ relative good performance.
  But when converted to p5.js framework, it somewhat let me down! :|

  You can check out all those versions here, including the p5.js version: http://forum.Processing.org/two/discussion/8997/hoppy-beaver

  And play it online through pjs framework here:
  http://Studio.ProcessingTogether.com/sp/pad/export/ro.9bTfM49wCIJza/latest
• GoToLoop

  June 2015 edited June 2015

  //this.elt.style.width = w + 'px'; //this.elt.style.height = h + 'px';

  Nice library hack... but we should avoid it whenever we can. :ar!
  Especially when we distribute the source for others to compile relying on the original lib! b-(

  Know that createCanvas() returns the p5.Renderer2D object of the newly created main canvas:
  http://p5js.org/reference/#/p5/createCanvas

  And that p5.Renderer2D inherits from p5.Renderer, which in turn does from p5.Element:
  http://p5js.org/reference/#/p5.Element

  Now the good part, all p5.Element instances got a property called elt which points to its actual HTMLElement: <:-P
  http://p5js.org/reference/#/p5.Element/elt
  https://developer.mozilla.org/en-US/docs/Web/API/HTMLHtmlElement

  And more precisely for the following building functions createCanvas(), createGraphics(), createImg(), createImage(), loadImage(), an HTMLCanvasElement:
  https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement

  In short, we can use for example the reference returned from createCanvas(), in order to access the underlying HTMLCanvasElement via p5.Element's elt property: \m/

  function setup() {
    const canvasElt = createCanvas(400, 600).elt;
    canvasElt.style.width = '100%', canvasElt.style.height = '100%';
    background(0100);
  }
  
• blindfish

  June 2015

  It's also worth bearing in mind that Processing is Java-based and your code is compiled; which means the interpreter can do all kinds of black magic to optimise it and have it run as efficiently as possible.

  p5.js on the other hand is JavaScript-based and so is interpreted by the browser. Different browsers have different JS engines and therefore varying levels of performance - e.g. IE7 was particularly bad - though most modern desktop browsers are in fact fairly good. Performance may still be poor on mobile devices that have lower specs. In fact some mobile browsers don't even process JS in the client; but do a round trip to the server (e.g. Opera mini). And as GoToLoop says if you've got a larger sketch size then you're processing a lot more information; especially true if you're trying to fill a retina display!

  The point is there are lots of factors that can affect performance; including the way you've written the code itself. In fact I suspect the latter can have far more impact in p5.js than in Processing. I've seen a few remarks about ProcessingJS having better performance than p5.js and I suspect this is partly the reason: PJS compiles the 'Java' code you write into JS - so there's an opportunity to apply optimisation - whereas p5.js runs the code as it is written...
• GoToLoop

  June 2015 edited June 2015

  PJS compiles the 'Java' code you write into JS - so there's an opportunity to apply optimisation - whereas p5.js runs the code as it is written...

  Actually the PJS transpilation into JS is prone to make the overall emit slower not faster! :-\"
  We can check out how a "JS Mode" code turns out as JS after the transpilation in the link below:
  http://ProcessingJS.org/tools/processing-helper.html

  Of course there's always a chance for us to write JS "pure" code worse than PJS' Java transpiled code! :-$

  PJS overall better performance over p5js framework is due to its much more mature code.
  P5JS is yet to start support for webgl canvas while pjs has it for a long time now for example! B-)
• GoToLoop

  June 2015 edited June 2015

  JavaScript-based and so is interpreted by the browser.

  Java "compiled" code is actually an intermediary format nicked byte code.
  Both Java & JS rely on a VM (Virtual Machine) in order to interpret the code into real machine code.
  Both Java & JS have many VM advanced optimization techniques like JiT (Just-in-Time compilation).
• blindfish

  June 2015

  OK - so I don't have a computer science background and should stop hypothesising based on half remembered articles and keep my mouth shut on this technical stuff :\">

  Or maybe not :P

  The main point I was trying to make is that whilst we can give general advice there may also be something in the code causing poor performance ;)
• GoToLoop

  June 2015 edited June 2015

  Neither do I! But nothing that Wikipedia or Stack Overflow couldn't "cure"! >:)
  Since he didn't mention anything about his actual code, we can't speculate too much about it.
  Most I did was confirming that canvas size indeed impacts sketch's performance, even in Java!
  But of course, written code quality is even more important! ~O)