The snippet in my OP calculates the coordinates for the rows.

For $width = 4; $height = 4; $qsize = 4; the output is:

01 [
02   [[0, 0], [0, 1], [0, 2], [0, 3]],
03   [[1, 0], [1, 1], [1, 2], [1, 3]],
04   [[2, 0], [2, 1], [2, 2], [2, 3]],
05   [[3, 0], [3, 1], [3, 2], [3, 3]],
06 ]
<code>

@queue should perhaps better been named @rows. Then:
<code>
01 my $queue = Thread::Queue->new();
02 $queue->enqueue(\@rows);
03 my @threads = map { threads->create( \&process, $queue ); } 1 .. 4;
04 ...
[download]

So, you're generating an AoAoA of pixel coorinates and enqueueing it. Let's compare doing that with just setting the pixels in the nested loops you use to generate the AoAoAs:

The result is:

c:\test>junk999
Filling a 1000x1000 pixel image 1-pixel at a time took: 6.491771936s
Populating 1000x1000 AoAoAs and tranferring to another thread took: 30
+.876082897s
[download]

It takes five times longer to build the AoAoAs and pass it to another thread for drawing, than it does to do that drawing in the main thread!

But what is the purpose of generating the coordinates and wrapping them up in the AoAoAs, only for the other thread to have to use nested loops to access them, when you could just pass 1000x1000 and have the other thread do the iteration itself.

And what is the point of passing the entire data structure as a single entity? Only one thread will be able to receive it; so there's not even the possibility of using concurrency.

Perhaps your intention is to do: $Q->enqueue( @cols ); (Ie. enqueue the contents of the array, not a reference to it.)

That way, the row arrays would be pushed onto the queue as separate entities; which means that different threads could dequeue individual rows and operate upon them concurrently. Assuming a thread-safe graphics library.

But even then what is the point in generating zillions of iddy-biddy arrays containing pairs of coordinates; when you could (say) push just the information required to construct them in the target thread:

# main thread
my( $X, $Y ) = ...;

for my $y ( 0 .. $Y-1 ) {
    $Q->enqueue( [ $X, $y ] );     
}

## drawing thread
while( my( $x, $y ) = @{ $Q->dequeue } ) {
    $image->setpixel( $_, $y, ... ) for 0 .. $X-1;
}
[download]

You need the same loop code in the thread as you would to unpack the AoAs; but you only need to transfer a 1000th or less of the information between threads.

Of course, the Devil is in the detail. Those ... above represent the color; and I assume that although you haven't shown it, the intent is to calculate the color for your Mandelbrot pixels in the main thread and farm off the drawing to the threads. And your (unshown) intention is to actually enqueue [ x, y, color ], [ x, y, color ] .... But that still doesn't make sense.

Why transfer the same y-coordinate a thousand times (or however wide your image is) for each row?

And why transfer a thousand X-coordinates when they can be inferred.

Ie. Do this:

## main
for my $y ( 0 .. $Y ) {
    my @colors;
    for my $x ( 0 .. $X ) {
        push @colors, Mandelbrot( $x, $y );
    }
    $Q->enqueue( [ $Y, @colors ] );
}

### thread

while( my( $y, @colors ) = @{ $Q->dequeue } ) {
    $image->setpixel( $_, $y, $colors[ $_ ] ) for 0 .. $#colors;
}
[download]

The Y-coordinate once, and a list of colors for the pixels is transfered, and the X-coordinates are inferred. (The problem of thread-safety remains.)