[Mono-dev] libgdiplus drawing performance

[Shade1974]

First, let me say, I have been really excited about the mono project and am
an enthusiast on the grounds that it potentially might allow us to take our
C# programming multi-platform.  We are developing a C# application that
needs to draw thousands of separate lines.  I have been having trouble with
getting drawing to work quickly.  This is one of those unfortunate scenarios
where it seems almost impossible to Google anything useful, and it took a
long time before I discovered that you could group thousands of lines
together into a single drawing path and draw them all at once with a single
call to the graphics device (GDI+ API).  This is on the order of THOUSANDS
of times faster, not merely one or two times as fast.  Now, imagine my
distress after having implemented this blazingly quick drawing in windows
only to discover that MONO seems to be unable to duplicate this
optimization.  I believe that the problem originates because the managed
mono wrapper must take the single DrawPath instruction and sub-divide it
into the individual calls to the API.  This might be necessary when talking
to Cairo, but I thought on windows this was simply supposed to forward the
instructions to GDI+.  The fact that even the windows implementation is slow
tells me that it's possible that the authors simply didn't know that there
was a huge performance gain by calling a chunky DrawPath instead of chatty
individual calls, or else they would at least have supported it in the case
of windows.

Anyway, like I said it took a huge amount of time before I even figured out
the optimization in the first place and I have just started to work with
mono.  It's quite probable that I am overlooking something straight forward,
but I'm having trouble figuring out what it is.  If anyone knows some
information that could help I'd be grateful.

Shade1974

-- 
View this message in context: http://www.nabble.com/libgdiplus-drawing-performance-tp19423752p23395461.html
Sent from the Mono - Dev mailing list archive at Nabble.com.