This by far is probably the easiest solution and provides a 2x increase in performance allowing me to draw a grid twice the size as before at 60 fps. Its not multithreading but it is better performance.
What is that applet argument you’re passing to registerMethod()?
You’ve gotta use your class’ reference so it calls back your class’ draw() method!
ooh ignore that, I thought it had something to do with the threads not being synchronized to the main render window, and thought linking and passing the main PApplet would help. It did not, assume the line to use this,. The code at the moment, more often than not just produces a gray box the size of the canvas, restart it, another gray box, restart it again, and the background is displayed, this is completely random and was reminding me of how the threads were just called randomly, so in my limited knowledge I thought pass PApplet. In any case, nothing but the background is drawn when something does happen.
Let me explain what the registerMethod() approach is suppose to achieve.
Your class A runs on its own Thread, but you can’t draw/mutate the sketch’s main canvas from it.
By using registerMethod() you can forward class A’s rendering parts to the sketch’s “Animation” Thread, leaving to class A’s Thread only the parts which isn’t about drawing.
As a workaround, you can have a separate PGraphics’s inside your class A, and leave to its registered customized callback draw() the task to display it.
out of curiosity, using the PApplet method do all the applet remain synchronised?
Ok gotcha so it can only accept regular canvas commands and nothing else. At least from what I understand.
if I change the code to the following
public void draw(){
background(50);
fill(0);
ellipse(0,0,width,height);
//display();
fill(255);
text("hello",50,50);
//System.out.println(count);
};
however add anything else and it just goes wonky.
PApplet is a class, so I don’t know which method you’re talking about.
Regardless, threads are responsible to execute all the code it passes through.
The matter here is that the way Processing library is programmed, its main canvas is exclusive to its “Animation” Thread to touch it.
I meant the PApplett approach not method…
1 Like
Thank-you to everyone for your contributions, I shall test all the methods suggested and post the various solutions later with and see which one performs the best.
Bit of a while since, I have been busy with various projects, but I just wanted to post back with a solution that I was happy with.
This solution makes no use of multi-threading and having looked into in it should provide some speed improvements when generating the grid itself.
Currently the solution I implemented was to use canvas and a PImage to store the perlin grid.
When update is on the grid draws all tiles to the canvas, just once then once completed the get() function is used to grab the canvas image. This produces something which is able to run 60fps no problem along all renderers, when fully loaded, and runs at around 20fps on FX2D when loading which is still acceptable.
This new method also allows greater resolution and size for the map;.
Also as per Sebastian Lagues suggestion in his procedural generation playlist, I have added frequency amplitute, octaves, lacunarity and persistance to increase the diversity that one can create with the grid.
Still 2d at the moment, but in combination with a sobel operator we can now have edges useable in real time withought any performance issues as the are once again calculated only once.
I shall hopefully try to complete this to add the other things from Sebastians playlist, eg chunks, shaders etc.
https://www.youtube.com/results?search_query=sebastian+lague+procedural
1 Like