Speed of C# and GDI+

  • Thread starter Thread starter =?ISO-8859-2?Q?Mateusz_=A3oskot?=
  • Start date Start date
?

=?ISO-8859-2?Q?Mateusz_=A3oskot?=

Hello,

I'm going to go with my project one of two possible ways
and I have to make some decisions. First, I'd like
to know more details and others experiences.

I have an ActiveX component which draws a lot of geometries
(lines, points,polygons) and manages
large amount of objects of geometries (hundreds and even thousands).
I would like to use it under Pocket PC with .NET
Compact Framework without the Odyssey CFCOM solution.
As we know, Compact Framework does not support ActiveX
hosting at all (natively).
So, there are two possibilities for me:

1 - try to make my ActiveX simple COM object without any GUI elements
and serving only data structures and geometries computations
and geometries would be drawn by GDI+ (.NET CF).

2 - use only C++ and native code.

The former would provide me with .NET advantages and faster
GUI development but as I know there are performance limitations.
Am I right ? What about my architecture of geometries rendering
using GDI + ? What about the performance ?
The latter solution gives me the best control over
my application and components, but it's harder
to develop GUI and other things.

If I'd choose the first one, I have to redevelop my ActiveX
to simple COM DLL wrapped by P/Invoke without any GUI objects
(no ActiveX elements).
The question is how it (P/Invoke, marshaling, etc.) will
influence the performance of my application ?
Are graphics operations under .NET CF fast ?
Is there any comparsion ?

Are there people having similar problems with making
decision about going unmanage C++ or managed .NET CF way ?
Could you share your experience ?

Thanks for any information !

BTW, I post it on two newsgroups,
microsoft.public.dotnet.framework.compactframework
and microsoft.public.pocketpc.developer.
If I broke netiquete, forgive me ;-)
 
I tried to use C# for a senior design project - it entailed plotting a lot
of points. I found C# to be extremely slow. For a start, I really hated that
when the application first came up the CPU activity would shoot to 100% for
a few secs (Ipaq 4155).

But presenting the demo of our project was a success because I was able to
make the demo very quickly, however, the real (working) app is now in C++.
 
just a question of curiosity.
how easy was it to migrate from C# to C++ ?

--
ihookdb
Get your data mobile
http://www.ihookdb.com


A.B. said:
I tried to use C# for a senior design project - it entailed plotting a lot
of points. I found C# to be extremely slow. For a start, I really hated that
when the application first came up the CPU activity would shoot to 100% for
a few secs (Ipaq 4155).

But presenting the demo of our project was a success because I was able to
make the demo very quickly, however, the real (working) app is now in C++.
Click to expand...
 
Hi Mateusz,

..NET CF compiler generates MSIL code which is a CPU independent
intermediate code. .NET CF converts MSIL code to appropriate machine
code when managed method executed for the first time. However this
conversion does not cause a very big performance issue for most of the
applications. At the end you are actually running the machine code,
..NET CF is not an interpreter. However .NET CF is a framework between
the operating system and your application. I can neglect the overhead
of that the framework layer but it may not be acceptable for your
applcation.

I would suggest you to develop two small test applications and measure
the performance between.

I prefer .NET CF as it abstracts the hardware differences and
eliminates problems such as byte alignment etc. So you do not need to
test on different platforms and single code runs PPC 2003 and PPC
2002. Designing the UI and implementing the application is also very
simple.


If it is acceptable to draw the screen after completing all the
processing and drawing, there is also third option.
You can do all you geometry processing in an eVC++ dll.
Within that DLL you can paint everything to a memory DC.

.NET CF classes does not expose a bitmap handle or window handle
which you can use from the unmanaged (eVC++) code. However the Bitmap
class provides a constructor which takes a stream parameter.

You can call your eVC++ dll and query the size of the bitmap as if
it was going to written to a file. With the returned value you can
create a byte array in your .NET CF code and call unmanaged dll again
with this array as the parameter.

In your eVC++ code you can fill this array with your result bitmap
which you can extract from memory DC. You can refer to codes on how to
write a bitmap to a file. The array should contain the same info in
the same order.

When your function returns with the filled array you can create a
memory stream out of it and use that stream as a parameter to bitmap
constructor.

This technique will work faster than you first scenario and eliminates
your performance concerns as the processing and drawing will be done
on the unmanaged code.

Ercan

keturkarslan at hotmail dot com
 
Since a eVC++ DLL is involved here, CPU dependence is back in? If this
trade-off for speed is necessary, while not compile the C# or eVB code to
native binary exe to avoid the JIT MSIL compiler phase? Is there a
way/option of doing this?
 
Back
Top