Re: GDI can be fast!

På Sat, 01 Apr 2006 16:48:21 +0200, skrev john chung <johnzulu[at]yahoo.com>:

I am also doing some test on this area. I am using C language for the
logic. Anyway I went with 32 bits since it is the fastest to
manipulate. I managed to get quite decent framerates by actually
manipulating the bitmap at the user mode level and just flush
the new bitmap with the BltBit function.

Yes. True. I was a bit too entusiastic. It really is fast, but using GDI bitblt is roughly about the same. The advantage of writing to memory directly comes from the potential that exists for doing things, not possible to do with GDI, and doing things _easier_ then GDI.

For instance, I now have allways complete command of every pixel. Even every pixel of a font. This means ability to play with functionality that would require a lot more code and forethought with GDI, and even DirectX provide.

Since I use memory, I can allways structure code so that I can just advance a pointer to the next pixel.This means in effect, that most code todo just about anything will never be much slower then bitblt, plus I can allways work at speeding up those key functions as I learn new ways.

If you want to run faster than intended than you have leave
GDI and go to DirectDraw as it communicates with the display drivers
directly.

Eventually yes. But using GDI for a GUI is not so easily portable to DirectX. I know this, because I tried. Writing to memory, is directly portable. This means that a GUI created for a desktop will also be useful inside of DirectX, at no cost.

Using the Directx.GetDC function lead to a SLOWER GUI rendering than using GDI. This was at least true for DirectDraw7.


Regards,
John
.

Relevant Pages

  • Re: c# and GDI graphics
    ... but the one main advantage that the DirectX solution has ... over the GDI app is that DirectX is going to utilize hardware acceleration ... whereas GDI won't (you are simply pushing pixels to the screen ... Is it possible to make an efficient GDI app? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Should I try to port from DirectX 9.0c to GDI+
    ... The only speed requirement I have is that the user can 'grab' the 3D view ... GDI and GDI+ don't handle those things directly. ... Systems like DirectX and OpenGL have convenient access ... If you can generate an RGBQUAD array the size of your draw region at ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: DirectX vs GDI
    ... If you want to learn about writing games, collisions, path finding and other ... It covers both GDI and Managed ... DirectX so you can compare and contrast and it walks through basic game dev ... > 7.0 so you don't need a separate SDK. ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: OnPaint Function Issue
    ... > Find great Windows Forms articles in Windows Forms Tips and Tricks ... > Answer those GDI+ questions with the GDI+ FAQ ... > GDI doesn't have a concept of double buffering. ... For the fastest possible speed make calls to the DirectX API's from the ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: From GDI+ to DirectX
    ... I'm about as new at DirectX as can be, though I am a seasoned application ... have a .Net bitmap object. ... or is its performance boost mainly in rendering to the screen? ... Now do realize that all the drawing commands available to you in GDI+ ...
    (microsoft.public.win32.programmer.directx.managed)
Loading