for (int x = 0; x < blockCountX; x++)
{
for (int y = 0; y < blockCountY; y++)
{
//get blocks from image to new image and send to threaded processor
imageBlocks[x, y] = image.Clone(clipRectangle, System.Drawing.Imaging.PixelFormat.Format8bppIndexed);
System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ParameterizedThreadStart(ThreadedFromHeightMap));
t.Start(imageBlocks[x,y]);
clipRectangle.Offset(0, IMAGEBLOCKSIZE);
}
clipRectangle.Offset(IMAGEBLOCKSIZE, clipRectangle.Location.Y * -1);
}
break;
}
}
private void ThreadedFromHeightMap(object Image)
{
Bitmap image = (Bitmap)Image;
int width = image.Width;
int height = image.Height;
for (int x = 0; x < width; x++)
{
for (int y = 0; y < height; y++)
{
map.Hexes.Add(new Point(x, y), new Hex(image.GetPixel(x, y).B));
//tempHexes.Enqueue(new Hex(image.GetPixel(x, y).B));
}
}
}
I'm trying to take pixel data from a 2048 x 2048 8bpp grayscale heightmap and building a hex map with corresponding height values. I'm storing the hexes in a Dictionary collection. All told there's ~4 million hexes in the collection.
To do this efficiently I'm breaking the image up into 256 x 256 chunks and passing that image to another thread which will parse it and add the hexes to the collection. This is were it all goes haywire. Instead of one image with (0,0) as its top left corner, I now have 64 image chunks that have (0,0) as their top left corner. However I'm using the pixel location as an index for the dictionary. This crashes when the second thread tries to add another value with index (0,0).
How do I mitigate this problem? I've thought about building a class that just has an image member and a chunk number member and pass that to the thread so I can adjust the pixel location depending on what chunk the thread is working on but that seems less than optimal.
(I realize the Dictionary I'm using isn't thread safe. I've since fixed that.)
May I recommend a few things?
Forget about image.GetPixel(), which is horribly slow; work directly with the bitmap data, and the performance of your algorithm will improve by so much, that you will not need to run parallel threads to improve its efficiency. See MSDN: http://msdn.microsoft.com/en-us/library/system.drawing.imaging.bitmapdata.aspx
If you insist on parallel threads, make use of the threadpool, instead of spawning 64 threads. (See MSDN: http://msdn.microsoft.com/en-us/library/3dasc8as(v=vs.80).aspx )
If you insist on spawning many threads, do NOT spawn more threads than the cores of your CPU. I do not suppose you have 64 cores on your machine, do you?
If you insist on spawning many threads, you will, of course, need to pass the location of each tile to the thread, so that you know exactly where that tile should be placed when you reconstruct the big picture. That's not less than optimal, it is necessary.
Why do you believe that breaking up the large image into smaller chunks will be more efficient? Is the large image too large to fit into system memory? 4million pixels x 8bpp (1 byte per pixel) = 4 megabytes. This was a lot of memory 20 years ago. Today it's chump change.
Creating multiple 256x256 sub-images will require copying the pixel data into new images in memory, plus the image header/descriptor overhead for each new image, plus alignment padding per scanline. You will more than double your memory use, which can create performance problems (virtual swapping) itself.
You are also spinning up a new thread for each image block. Allocating a thread is very expensive, and may take more time than the work you want the thread to do. Consider at least using ThreadPool.QueueUserWorkItem
to make use of already available system worker threads. Using .NET 4.0's Task
class would be even better, IMO.
Forget .GetPixel(). It's a thousand times slower than pixel memory access.
If you want to distribute processing the image pixels across multiple CPU cores, consider processing each scanline or group of scanlines to a different task or worker thread.
image.Scan0
if you don't have any restriction about unsafe operations. Parallel.ForEach
for such usages. If you can't use it, you can use thread pools. I guess your computer does not have (2048 x 2048) / (256 x 256) = 64 core CPU.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.