We are about to switch to a new forum software. Until then we have removed the registration on this forum.
i am developing a game for a hardware device we made. However, it does not render smoothly on my mobile devices when i set the canvas to full screen. is there anyway to improve the performance of p5.js. please help!!!!!! cheers. BTW can i set the canvas to a moderate size for p5 to render and then scale up for display?
hey there i guess i have worked it out. So here is my solution,
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';
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
attach a css style sheet to your html, specify the canvas size to width:100% height:100%
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???
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
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:
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:
And that p5.Renderer2D inherits from p5.Renderer, which in turn does from p5.Element:
Now the good part, all p5.Element instances got a property called elt which points to its actual HTMLElement: <:-P
And more precisely for the following building functions createCanvas(), createGraphics(), createImg(), createImage(), loadImage(), an 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/
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.
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...
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:
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-)
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).
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 ;)
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)