Is .net code going to be faster in future?

[aewarnick]

divil, you said this:

The reason .NET programs are generally slower than their C++ counterparts is not because of slow executing code, but because a lot of .NET is still a wrapper to win32 functions. This wont always be the case though.

How do you know and when do you think it will happen with the Graphics and Drawing part of the framework?

 

[pjv]

Hi,

They have a team whose only responsibility is to improve the performance of the framework. As for Graphics, I suppose there might be support for hardware acceleration in future versions of GDI+ (which would be a vast improvement in speed), but GDI+ isnt managed code anyway, so its not specifically part of .net (I believe).

Pete

 

[mutant]

Originally posted by pjv
but GDI+ isnt managed code anyway, so its not specifically part of .net (I believe).

GDI+ is a part of the Framework, its built right into it.

 

[pjv]

Im pretty sure GDI+ is unmanaged code.. the System.Drawing stuff is just wrappers for it. Check here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdicpp/gdiplus/gdiplus.asp

Or a quote:

"Microsoft Windows GDI+ is a class-based application programming interface (API) for C/C++ programmers"

Which must mean its unmanaged, or how would it be used by C programmers?

Pete

 

[OnErr0r]

C++ programmers have a choice of using MC++ and the managed .net wrapper, or they could use the C++ classes written to wrap the gdiplus.dll directly. In VB5/6 you can use the exports of the gdiplus.dll as well.

 

[aewarnick]

Ok, you are all correct about GDI+ being part of the framework and a new api.

What I am hoping is that this new api with improvements can be as fast as GDI is.

 

[pjv]

No. GDI+ is NOT part of the framework. It is a completely separate API (which is unmanaged). Ive heard that there is a new version coming, but whether that will coincide or not with the next .NET release, I dont know.

It is unlikely that it will work at GDIs speeds. Even if the next GDI+ version enables hardware vendors to accelerate it, it will be some time before graphics cards support it. It might be considerably faster than it is now, but it still wont work at GDIs speeds.

Note that some graphics vendors claim their new cards are "GDI+ Accelerated". According to a recent thread on microsoft.public.dotnet.framework.drawing, all they can do is accelerate GDI (and therefore the parts of GDI+ that call GDI directly). Not too sure how reliable this info is (was posted by an ms employee, but not necessarily one working on GDI+).

Pete

 

[Volte]

GDI+ is indeed a separate API library (it can be used from VB6 if you want, using COM wrappers), but I believe the .NET implementation is a set of managed wrappers for GDI+; although GDI+ itself is unmanaged, I believe the .NET wrappers are managed.

 

[aewarnick]

That is why it seems that GDI+ is part of the framework itself, because it is wrapped. Well, in a sence it is part of the framework;;;; it installs when you run the .net framework install file. I see your point though.