• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# is windows gdi hardward accelerated?

## Recommended Posts

thuned    122
functions like ::StretchBlt, ::BitBlt, ::DrawDibBits, ::StretchDIBits. I did some testing and it appears that it does speed up significantly when I use these functions with a better video card. Will using real directdraw be able to add any more performance?

##### Share on other sites
Oluseyi    2103
Tons.

GDI+ has the potential of being optimized, but plain GDI isn''t necessarily (and as such you shouldn''t rely on it for high performance graphics).

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

##### Share on other sites
daerid    354
GDI should be used to develop Windows Desktop Applications, not games.

##### Share on other sites
Arild Fines    968
Most of GDI should be accelerated in some fashion. GDI+ currently isnt, except for where it relies on existing GDI calls. This will eventually change as video card manufacturers catch up.

The computer was conceived as a tool to reduce complexity. Some people found this loss of complexity unacceptable, and developed UNIX to amend the situation.

##### Share on other sites
Guest Anonymous Poster
isn''t any GDI stuff accelerated (really through DirectDraw) ? at least in newer versions of windowze? even when i load some openGL program it loads stuff out from DirectDraw dll''s (for resolution switching and so on) ...

##### Share on other sites
DrPizza    160
GDI is accelerated too a fairly large degree, GDI+ is to a significantly smaller degree.

##### Share on other sites
thuned    122
sorry, i have no idea what gdi+ is; can anyone tell me? are those functions i''ve listed gdi or gdi+? and this isn''t really a game but i need the performance. i''m manually processing video frames and outputing bitmap (hbitmap handles) to the screen. the performance is fine usually, but on my crappy video card (savage2000), if i use stretchblit and zoom in, it''ll be ultra slow. just wondering if i use directdraw it''ll be faster.
i don''t know directdraw currently and don''t really want to learn it unless i have to.

##### Share on other sites
a person    118
gdi is accelerate by most video venders. if its not acelerated through gdi, then directdraw wont accelerate it either. the problem is the gdi gves you less control on what resolution you use, and what it will use. ALL gdi functions that are accelerated, are only accelerated IF you are doing everything with the same color depth as the screen. directdraw will not give you much performence increase in windowed modes, unless you require forcing certain things into vram (gdi decides for you, and ussually keeps most things in system ram). i noticed no speed increases using dd vs gdi in windowed apps that do per pixel operations. if anything, dd makes initilizing more difficult and cumbersome. plus dd in coop mode (what windowed apps must be in) must not intefere with the gdi anyway. plus the gdi accelerates line drawing on most cards. now things like stretching may be slow because your card is slow or the vendor choose not to implement accelerated functions. also make sure that everything is in the same colordepth, the only reason the gdi will be slow is because of colordepth conversions.

##### Share on other sites
thuned    122
thanks man. so all i need to do is to detect the color depth and make sure my bitmap is the same depth then i can stretchblit to the screen? is there a function that converts color depths (for bitmap or raw image data) that i can use?

##### Share on other sites
Kippesoep    892
You can always StretchBlt. GDI will do the conversion for you. If it has to be in software, that can be terribly slow. One way to prevent this is to create a memory DC that is compatible with the current screen display. Then, create a bitmap in the same format. Blit your stuff into that once (to do the colour conversion) and then blit to the screen from there subsequently. It would probably be better to do the stretching into the memory DC as well, so you can use regular BitBlt to blit to the screen.

Something like this

  //Prepare the handlesHDC memDC = CreateCompatibleDC (NULL);HBITMAP memBitmap = CreateCompatibleBitmap (memDC, targetW, targetH);HBITMAP oldBitmap = (HBITMAP)SelectObject (memDC, memBitmap);//Do stretch and colour conversionStretchBlt (memDC, ...);//Everywhere else, just do:BitBlt (targetDC, ..., memDC, ...);//Don''t forget to clean up the mess on the kitchen floorSelectObject (memDC, oldBitmap);DeleteObject (memDC);DeleteDC (memDC);