Re: The story: Painting bitmap to screen is slow

Hello Tomaz,

Do you have source code for your test?

The general "trick" behind great GDI+ performance is to do all drawing
off-screen onto a single bitmap (all in system memory), then draw that
single bitmap to the screen. Only drawing the portions that have been
modified is faster than drawing the whole thing.

My own experience is the final transfer of the bitmap to the screen, always
using 32bppPArgb, may be the slowest part of drawing. Not the drawing on the
bitmap itself.

I heard Microsoft broke GDI acceleration for some operations in Vista.
Perhaps the GDI bitblit operation, used by GDI+ was broken. Still it is hard
to believe it could be as poor as you post; it may have something to do with
your configuration of Vista (glass?) or graphics driver. A GDI bitblit test
would confirm that.

When I first heard stories about GDI versus GDI+ performance, we started to
use GDI bitmaps to see if they were faster. For our system, using 32bpp
bitmaps, there was not much performance difference, so we abandoned that
approach. If Vista is bottlenecking GDI transfers, it won't make any
difference now either. It is possible to have a GDI+ and GDI bitmap both
refer to the same area of memory, so you can use either API to transfer to
the screen.

Since WPF performance is terrible and DirectX doesn't have the necessary 2D
graphics operations, it is hard to believe Microsoft would kill GDI/GDI+ on
Vista, as it is needed for complex graphics. Also 50% of 100fps is not
12fps, it is 50fps?

--
Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio graphics editor


"TomazK" <tomaz@xxxxxxxxxxx> wrote in message
news:uBDqhlluIHA.576@xxxxxxxxxxxxxxxxxxxxxxx
A little story about GDI+ performance.







I've done a lot graphics programming by now and the thing that bothers me
with GDI+ in .NET framework the most is slow drawing of bitmaps to screen.
I usually do this on the control's OnPaint event or drawing it directly to
its graphics interface (using CreateGraphics).



I've heard a lot about GDI+ slow performance and mostly everybody say it's
because it's not hardware accelerated. Now I don't want to talk about
drawing shapes onto Graphics class but I will mainly talk about drawing
bitmaps to screen which is the most essential part of any graphics
library. What puzzles me is why is drawing bitmaps to screen so slow? Let
me give you some numbers for example. All tests were performed using 32bit
full-screen bitmaps and 32 bit desktop color depth on a WindowsXP. By
saying full-screen, I mean drawing on the maximized window where bitmap
size is exactly the same as client area of this window. I usually worked
with resolution 1152x864 which is by these days low resolution.



In Win32, there were two types of bitmaps, compatible and memory bitmap
(Memory bitmap can be a GDI DIB Section or a plain simple memory buffer
which has nothing to do with GDI). Drawing a compatible bitmap to screen
was of course super fast as bitmap was already located inside graphics
card memory. This easily gave 1000+ fps and was indeed hardware
accelerated. With memory bitmap located in system RAM, drawing to screen
involved copying bitmap's data from RAM to video card which was a lot
slower but still very fast though it was very much dependent not so much
of the graphics card, but of the interface speed (AGP 2x, 4x, 8x, PCIe),
motherboard and probably the processor. PCIe gives a real speed boost
here. This gave me i.e. 100fps on AGP8x, and after I switched to a much
better motherboard (all other components are the same), it gave me 300fps.
This was not hardware accelerated as HW acceleration can only be done
inside graphics card. This fps is more than enough for any desktop
graphics performance.



Now let's come to .NET framework and GDI+ behind it. The bitmap for
testing was constructed using a main form's graphics class to make bitmap
as compatible (regarding color depth) with screen as possible. Drawing
such bitmap was much slower. It was some three times slower than drawing
memory bitmap in using GDI. I usually got some 100fps (with previously
mentioned new motherboard) which is still not bad. Now the best part. When
I switched to Vista (with or without SP1, it doesn't really matter cause
it's the same), the drawing was even worse. I don't know the exact number
but it was even up to 50% slower. That is all on low resolutions.



The conclusion. How can a person make a descent graphics library for
desktop apps, when the most basic operation of any such library is very
slow, that is drawing all that beautiful contents onto screen for people
to see. Again, "experts" will tell you that's because GDI+ is not hardware
accelerated. But I don't believe this because for comparison, how can GDI
draw memory bitmaps so fast. Why can't GDI+ do the same because it
probably uses the same bitmaps or memory buffers at least. Is GDI+ doing
something extra while drawing bitmaps? What and how to make it stop doing
that. It just doesn't make any sense. Switching to other GDI+ bitmap's
pixel formats makes drawing even slower (PARGB included).



At the end, let me show you the performance on Vista (SP1) and on a huge
24" monitor. Machine configuration: Intel Core2Duo 2.13GHz, 2GB RAM, 32bit
desktop of size 1920x1200, NVIDIA Quadro NVS 290 Graphics card. We all
agree that my machine is not a slow one and it's probably more (or at
least equal) than the machine average user has these days. The drawing
speed is astonishingly 12fps :). Now imagine how slow it will become when
I start drawing something onto this bitmap...





best regards

TomazK



.

Relevant Pages

  • The story: Painting bitmap to screen is slow
    ... I've done a lot graphics programming by now and the thing that bothers me with GDI+ in .NET framework the most is slow drawing of bitmaps to screen. ... In Win32, there were two types of bitmaps, compatible and memory bitmap. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Pen width difficult to control with scaled graphics
    ... There doesn't seem to be a workaround except drawing some of the graphics at scale and then others unscaled using the matrix but scaled manually. ... Answer those GDI+ questions with the GDI+ FAQ ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: large bitmaps for printing (GDI+)
    ... None of the 16 bpp image formats work under GDI+. ... CAD drawings to plotters are usually defined in a vector graphics format ... If you have the possibility of breaking the drawing up into smaller chunks ... I allocate a 16bpp bitmap and then> draw to it. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Problems drawing GDI+ text
    ... The example in this document clearly demonstrates how to manipulate the Bitmap and its related Graphics object to do the kind of drawing I want to do. ... Guess I'll take a trip to Microsoft Connect and ping the documentation. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: The story: Painting bitmap to screen is slow
    ... GDI bitmap pointing to the same area of memory. ... onto a Graphics device context. ...
    (microsoft.public.dotnet.framework.drawing)
Loading