is windows gdi hardward accelerated?

Started by
8 comments, last by thuned 22 years ago
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?
life is unfair, take advantage of it.UNMB2 - if the link doesn't work, try clicking it :)
Advertisement
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!
GDI should be used to develop Windows Desktop Applications, not games.
daerid@gmail.com
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.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
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) ...
GDI is accelerated too a fairly large degree, GDI+ is to a significantly smaller degree.
char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;}  /*** drpizza@battleaxe.net ***/
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.
life is unfair, take advantage of it.UNMB2 - if the link doesn't work, try clicking it :)
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.
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?
life is unfair, take advantage of it.UNMB2 - if the link doesn't work, try clicking it :)
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);  


Kippesoep

This topic is closed to new replies.

Advertisement