Can 4 threads draw in one display at once?

Programming Questions

hamoid

Can 4 threads draw in one display at once?

in Programming Questions • 1 year ago

Hi! I'm trying to optimize a program by dividing one task into four threads. On each frame I want to draw 10 collections of 600 lines, so I'm creating four threads. The first two draw 2 collections, the next two 3 collections (2+2+3+3=10).

The lines must be drawn using rect() because if I use line() there are very ugly position rounding errors. That means I must translate() and rotate() the rect() into the right position. If I used lines I could just calculate the position of both ends and avoid translating and rotating.

Now, the result is quite cool and messed up :) Not exactly what I want. The problem is (I think) that each traslate() and rotate() is interfering with the other calls to the same functions in the other threads, so the translations and rotations pile up. I even get some crazy huge rectangles for free.

Can this problem be distributed at all into several threads?

void setup() {
size(600, 300);
colorMode(HSB, 1);
noStroke();
smooth();
}
void draw() {
background(0);
float f = frameCount / 88.0;
SimpleThread t1 = new SimpleThread(0, 1, f);
t1.start();
SimpleThread t2 = new SimpleThread(2, 3, f);
t2.start();
SimpleThread t3 = new SimpleThread(4, 6, f);
t3.start();
SimpleThread t4 = new SimpleThread(7, 9, f);
t4.start();
if (frameCount % 50 == 0) {
println(int(frameRate));
}
}
class SimpleThread extends Thread {
int yfrom;
int yto;
float f;
SimpleThread (int from, int to, float rf) {
yfrom = from;
yto = to;
f = rf;
}
void run () {
for (int y = yfrom; y <= yto; y++) {
float they = y/10.0;
for (int x=0; x < width; x++) {
float thex = x/100.0;
fill((they + thex + f) % 1.0, 1, 1);
translate(x, 50+y*20);
rotate(they + thex + f);
rect(0, 0, 1, 15);
resetMatrix();
}
}
}
void quit() {
interrupt();
}
}

I know it would be more efficient to create 4 threads once instead of making new ones all the time, but I have no idea (yet) about how to keep them in sync with draw().

Replies(8)

hamoid

Re: Can 4 threads draw in one display at once?

1 year ago

Now I see more errors in my program. If I deactivate all but one thread, it still does not draw the complete thing. Is it because the thread is garbage collected?

Or the background(0); is called when drawing is not yet finished?

Now I see why multicore programming is complicated :)

hamoid

Re: Can 4 threads draw in one display at once?

1 year ago

Another attempt, now reusing the four threads instead of creating new ones all the time.

I use a counter to call background(0) only after drawing 4 times. But I know it's wrong to assume that the counter indicates threads 1, 2, 3 and 4 have done their job. Maybe one thread finished twice, decreasing c two times, and another thread never finished.

And still the rotates and translates are probably fighting each other.

Any suggestions?

SimpleThread t1 = new SimpleThread(0, 1);
SimpleThread t2 = new SimpleThread(2, 3);
SimpleThread t3 = new SimpleThread(4, 6);
SimpleThread t4 = new SimpleThread(7, 9);
float pF;
int c = 4;
void setup() {
size(600, 300);
colorMode(HSB, 1);
noStroke();
smooth();
t1.start();
t2.start();
t3.start();
t4.start();
}
void draw() {
if (frameCount % 50 == 0) {
println(int(frameRate));
}
}
class SimpleThread extends Thread {
int pFrom;
int pTo;
SimpleThread (int tFrom, int tTo) {
pFrom = tFrom;
pTo = tTo;
}
void run () {
while (true) {
try {
if(c < 1) {
c = 4;
pF = frameCount / 88.0;
background(0);
}
c--;
for (int y = pFrom; y <= pTo; y++) {
float they = y/10.0;
for (int x=0; x < width; x++) {
float thex = x/100.0;
fill((they + thex + pF) % 1.0, 1, 1);
translate(x, 50+y*20);
rotate(they + thex + pF);
rect(0, 0, 1, 15);
resetMatrix();
}
}
sleep((long)(20));
}
catch (Exception e) {
}
}
}
void quit() {
interrupt();
}
}

hamoid

Re: Can 4 threads draw in one display at once?

1 year ago

One more try. It starts to look like what I want to do is not doable.

In this case I use flags to make sure each thread has completed it's part. I also deactivated translate and rotate, and this was a new revelation: fill() is also conflicting. So when one thread chooses a color, it's affecting the shapes drawn by other threads.

The worst part is that if I comment the fill() out, and we then see a black and white image, even that has defects. Since all the variables that change are local, it means that even the single rect() that is left is somehow conflicting between threads.

Deactivating all but one thread confirms this: the effect then looks fine. You can deactivate the threads by commenting out t2.start(), t3.start() and t4.start(), and replacing 0x0F by 0x01 twice.

So after all these experiments, the question is:

Is it somehow possible to have several threads updating the display without conflicts? Limiting ourselves to updating the pixels[] array is not a valid answer :)

SimpleThread t1 = new SimpleThread(1 << 0, 0, 1);
SimpleThread t2 = new SimpleThread(1 << 1, 2, 3);
SimpleThread t3 = new SimpleThread(1 << 2, 4, 6);
SimpleThread t4 = new SimpleThread(1 << 3, 7, 9);
float pTime;
int pReady = 0;
void setup() {
size(600, 300);
colorMode(HSB, 1);
noStroke();
smooth();
background(0);
t1.start();
t2.start();
t3.start();
t4.start();
noLoop();
}
void draw() {
if (frameCount % 50 == 0) {
println(int(frameRate));
}
}
class SimpleThread extends Thread {
int pFrom;
int pTo;
int pID;
SimpleThread (int tID, int tFrom, int tTo) {
pID = tID;
pFrom = tFrom;
pTo = tTo;
}
void run() {
while (true) {
try {
boolean act = true;
synchronized(g) {
// if all threads have finished
if (pReady == 0x0F) {
pReady = 0;
pTime = frameCount / 88.0;
background(0);
}
// if this thread is done, don't draw
if ((pReady & pID) != 0) {
act = false;
}
}
if (act) {
for (int y = pFrom; y <= pTo; y++) {
float they = y/10.0;
for (int x=0; x < width; x++) {
float thex = x/100.0;
fill((they + thex + pTime) % 1.0, 1, 1);
//translate(x, 50+y*20);
//rotate(they + thex + pTime);
//rect(0, 0, 1, 15);
//resetMatrix();
rect(x, 50+y*20, 1, 20);
}
}
synchronized(g) {
// mark this thread as finished
pReady |= pID;
if (pReady == 0x0F) {
// if all threads are done, update the screen.
redraw();
}
}
}
sleep((long)(106));
}
catch (Exception e) {
println(e);
}
}
}
void quit() {
interrupt();
}
}

Greger

Re: Re: Can 4 threads draw in one display at once?

1 year ago

You could try to have each thread have its own PGraphics instance (backbuffer),
and then have a main thread just add all those buffers together in the main window.

quarks

Re: Can 4 threads draw in one display at once?

1 year ago

Is it somehow possible to have several threads updating the display without conflicts?

The short answer is no.

This may change (but probably not) as the Java language is changed to better use multicore processors.

Attempting to update the display in multiple threads is never a good idea since you are never sure when a thread will become active or when it will release control to the other threads. So one thread sets the fill color only to release control to another thread that then draws a rectangle ...

The most common use of Threads is to run large (non GUI) background tasks.

Just noticed Greger's response - that should work provided the 'back buffers' use a transparent background.

byhring

Re: Can 4 threads draw in one display at once?

1 year ago

The last bit of code you posted gave me an FPS of 9 (Quad core processor).

When I altered the first post you made a little bit to remove all multithreading, I got a FPS of 30 (115 if I switch to OpenGL, but then I get some unwanted artifacts).

Allthough it certainly has educational value, making this program multithreaded doesn't seem worth it :(

hamoid

Re: Can 4 threads draw in one display at once?

1 year ago

I made it :) Not elegant but it works. I post first here the non threaded version which runs at 26 fps on my laptop:

void setup() {
size(600, 300);
colorMode(HSB, 1);
noStroke();
smooth();
}
void draw() {
background(0);
float f = frameCount / 88.0;
for (int y = 0; y < 10; y++) {
float they = noise(y/10.0);
for (int x=0; x < width; x++) {
float thex = noise(x/50.0);
fill((they + thex + f) % 1.0, 1, 1);
translate(x, 50+y*20);
rotate(6*they - 6*thex - f);
rect(0, 0, 1, 15);
resetMatrix();
}
}
if (frameCount % 50 == 0) {
println(int(frameRate));
}
}

And the threaded version using four cores runs at 43 fps:

Renderer t1;
Renderer t2;
Renderer t3;
Renderer t4;
float pTime;
int pReady = 0;
int pAllReady = 0;
void setup() {
size(600, 300);
colorMode(HSB, 1);
background(0);
noLoop();
frameRate(100);
t1 = new Renderer(1, 0, 1);
t2 = new Renderer(2, 2, 3);
t3 = new Renderer(4, 4, 6);
t4 = new Renderer(8, 7, 9);
t1.start();
t2.start();
t3.start();
t4.start();
}
void draw() {
if (frameCount % 50 == 0) {
println(int(frameRate));
}
}
void render() {
background(0);
t1.flash();
t2.flash();
t3.flash();
t4.flash();
pReady = 0;
redraw();
}
class Renderer extends Thread {
PGraphics pGfx;
int pFrom;
int pTo;
int pID;
Renderer (int tID, int tFrom, int tTo) {
pID = tID;
pAllReady |= pID;
pFrom = tFrom;
pTo = tTo;
// each thread renderns on its own PGraphics
pGfx = createGraphics(width, height, JAVA2D);
pGfx.beginDraw();
pGfx.colorMode(HSB, 1);
pGfx.noStroke();
pGfx.smooth();
pGfx.endDraw();
}
// place this layer onto the main display
void flash() {
image(pGfx, 0, 0);
// make this layer transparent again
pGfx.background(0, 0);
pTime = frameCount / 88.0;
}
void run() {
while (true) {
boolean act = true;
synchronized(g) {
if (pReady == pAllReady) {
render();
}
else if ((pReady & pID) != 0) {
// if this thread is done, don't draw
act = false;
}
}
if (act) {
pGfx.beginDraw();
for (int y = pFrom; y <= pTo; y++) {
float they = noise(y/10.0);
for (int x=0; x < width; x++) {
float thex = noise(x/50.0);
pGfx.fill((they + thex + pTime) % 1.0, 1, 1);
pGfx.translate(x, 50+y*20);
pGfx.rotate(6*they - 6*thex - pTime);
pGfx.rect(0, 0, 1, 15);
pGfx.resetMatrix();
}
}
pGfx.endDraw();
// mark this thread as finished
synchronized(g) {
pReady |= pID;
}
}
try {
sleep((long)(8));
}
catch (Exception e) {
println("Oh " + e);
}
}
}
void quit() {
interrupt();
}
}

It's questionable if it's worth it, but it really was an interesting challenge :) For 4x the cores I get 1.65x the speed. Maybe it can be still optimized. One thing I don't really understand is how the frameRate(100) relates to the sleep((long)(10)); Both control the speed.

Lowering the the amount of sleep milliseconds increases the speed, but when it's too low there is random flickering going on. But if the frame rate is low, even noLoop(); is executed, then frame rate is low independently of the milliseconds.

I find the amount of calculations the computer is doing each second amazing :)

hamoid

Re: Can 4 threads draw in one display at once?

1 year ago

I'm surprised, but now running the same exact examples I posted above I no longer get a great difference in speed between using threads or not. ~~I don't know why I was getting those numbers earlier.~~ See below.

I did a ton of testing with no threads, 1, 2, 3 and 4 cores. I started measuring the speed this way, which is more precise when you wait for a minute:

if (f++ % 50 == 0) {
println((1000*f / millis()) + " : " + (1000*frameCount / millis()) + " : " + frameRate );
}

The numbers I'm getting now are 39 fps for single thread, 42 fps using 4 cores and, this is interesting, when the 4 cores are no evenly loaded. If I split the work in 4 identical parts it goes down to 39 fps. If I load them 2/3/2/3 then I get 42 fps.

But obviously the advantage, at least for this example, is tiny.

I will edit this comment to add a link to the source code that lets you test this kind of layered rendering on any number of cores, in case you are curious.

Update:

I realized why I was getting such different results. It turns out that in Processing 1.5.1 both single and multi threaded get around 40 fps. In Processing 2.0a4 , single thread gets 26 fps, four threads achieve 42 fps.

Here the source code for single and mulithreaded tests.

Update 2:

After all this optimization works this feels very silly: a 600x300 program in Processing 2.0a4 that erases the screen and draws a small circle having smooth() activated renders at 44 frames per second. That means that something is limiting the frame rate and is not the complexity of the program. That means that no matter what wicked tricks I would use to increase the frame rate, I could never go past 1 FRC (Frame Rate of the Circle). I get almost the same rate with:

A program that draws one small circle per frame.
A program that uses four synchronized threads to draw 6000 antialiased, colored, translated and rotated rectangles into four virtual layers with alpha channel that are then combined into one, on each frame.

Anyone knows why? I'm curious...

Last update I promise :)

Since the frame rate was not very different between drawing one circle and drawing 6000 shapes on 2.0a4, I thought maybe I was not pushing it hard enough. So I increased the iterations to 10000. In that case Processing 1.5.1 is no longer able to run smoothly, the fps goes down to 16. The same code running on four threads stays above 22 fps. The difference is even greater in 2.0a4, 13 fps vs 22 fps. That means rendering in parallel can be useful at times. Though I wonder why the increase is not greater.