[Advanced] GDI+ Rendering in multiple threads

Question

Hi,

 

As far as I could gather, GDI+ is limited to one operation at a time in a single process. This makes parallel processing of GDI+ operations impossible, therefore there is no advantage with multiple cores and GDI+.

 

Does anyone know a way to do concurrent GDI+ operations in .NET?

 

Thanks,

Kevin

 

(I mark answers)

Answer 1

GDI+ is but one of many Microsoft libraries that cannot handle concurrency.  The .NET framework itself is largely incapable of it without generous use of the lock statement.  Thirty+ years of research in parallel programming hasn't as yet produced a simple solution.  It is going to take an entirely different way of programming and that takes time.  Maybe Chris Brumme's super-secret new project has something to do with it.  Let's hope.

Answer 2

Thanks for the answer. I tried WPF and it works in parallel

Answer 3

Just out of curiosity, how did you know GDI+ does not support concurrency? I have googled the heck out of this one (for hours) and I cannot find any official or even unofficial documentation regarding this problem.

Answer 4

Almost without exception, a library isn't thread-safe unless the documentation explicitly says it is.  The docs for the Graphics class actually says it isn't in the Thread Safety section.

Answer 5

Well, as you already know, there is a difference between a library that is

 

1. Not thread safe

2. Locks calling threads to a single thread of execution.

 

GDI+ does both. In GDI+ if you were to do the following in two separate threads:

 

1. Create large bitmap

2. Get Graphics from bitmap

3. Perform a large drawing operation on bitmap

 

Even through the objects are independent, internally GDI+ will globally lock the drawing operation so that it can only happen on one thread. When I think of "Not Thread Safe" I think of a user attempting to use a single instance in multiple threads. That will obviously cause problems.

 

I just found it interesting that GDI+ has this global "internal lock" for most of its (instance) methods.

 

Thanks again,

Kevin

Answer 6

Okay, agreed, that's not the same thing.  Hard to tell why that global lock is used but, no doubt, there to protect private state.  The native heap allocator and debug and notification hooks might have something to do with it.