# [.net] Blitting Images (gdi vs gdi+)

This topic is 4873 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Blitting in .NET 1.1 is really damn slow using graphics.DrawImage (or unscaled image with all settings on speed). I decided to use gdi. The unstretched blit is about a dozen times faster (0.007 seconds) and the stretched blit comes in at roughly 2ms. Still way faster than the .net way. I really don't like working with gdi directly as it would be nice to just have Bitmaps instead of both hbitmaps and bitmaps (i need something in the form of bitmap for somewhere else in the code, plus re-writting is a drag). My first question is will .NET framework 2.0 speed up the blitting?? My 2nd question has to do with this curious bug. The stretchBlt works nicely when zooming in but when shrinking i notice a lot of distortion (particularly a grid that forms, much like graphing paper). It's not because of a nearest neighbour algorithm. Zoom is a double where 1.0 is 100%. If there's a better way to do what i want i'm all ears. I do not like this kludge of mixing gdi and gdi+ .net
//g is the graphics object myPictureBox in this case.
//hmemDC is the unscaled HBitmap.
IntPtr hdc = g.GetHdc();
StretchBlt( hdc, 0,0, this.Width, this.Height, hmemDC, origin.X, origin.Y,(int)(this.Width/zoom), (int) (this.Height/zoom),(int)TernaryRasterOperations.SRCCOPY);
g.ReleaseHdc(hdc);


##### Share on other sites
.NET 2.0 will most probably not speed up the drawing.
.NET relies on GDI+, which has nice features over GDI, but which is sadly not hardware accelerated. Ms was planning to HW-accelerate it, but since they are now working on Avalon, I doubt they will.

GDI is hardware accelerated, which explains why it's faster. If you need high performances graphics, consider using it, or DirectX, OpenGL.

For StretchBlt I'm sorry not being of much help, because I haven't been using GDI for quite a long time now...

Have a nice day,
jods

##### Share on other sites
I supposed i would have given managed-directx a try, but its not much of an option for this project. Maybe I'll look into Tao sdl and others but i think they will "dirty" things up just as bad as gdi.

How could gdi+ not be hardware accelerated??? That's rather silly. If they wanted people to switch from gdi to gdi+ it really makes no sense.

Thanks for the insight!

##### Share on other sites
Well, I think the process is quite natural: they built a whole new API (first version being software, of course) and released it, promising to add hw-acceleration to the next release. Then comes longhorn... :-(

Note this is only wild guesses from me, I have no knowledge of what really happens at Ms. GDI+ is a very nice drawing library and I also think it's a pity that it's so slow...

Maybe this will help you a bit: GDI+ uses the same resources as GDI to render what can be rendered with GDI. And so these operations are hw-accelerated, even in GDI+. So you should be able to get a fast blitting in GDI+, if you uses parameters that allows GDI to do the job (i.e. disable alpha-blending, anti-aliasing, and so on).

jods

##### Share on other sites
Another post from me but i thought i'd give managed directx a try. I have to do some drawing to the image so i might as well go all the way.

The documentation and microsoft's site seem to be malfunctioning quite a bit lately.

Some basic questions:

Redistribution: Does managed directx get bundled with direct redistributable or .net runtime.

##### Share on other sites
Two solutions to install the Managed DX runtime:
Install Managed DirectX

Some applications also simply deploy the needed DLLs in the same directory they are installed... Not a very good practice, but of course it works.

1. 1
Rutin
29
2. 2
3. 3
4. 4
5. 5

• 13
• 13
• 11
• 10
• 13
• ### Forum Statistics

• Total Topics
632961
• Total Posts
3009482
• ### Who's Online (See full list)

There are no registered users currently online

×