0

This is a follow on to my previous question Speeding Up Image Handling

Apologies if I should have amended that question in some way rather than starting a new one.

I have tried all sorts of different things to speed up the drawing of an image on screen.

I thought that compressing the image until it is smaller would have an effect. However while this might save memory for the object I do not think it has any effect on how long it takes to draw. I tried converting the image to jpeg and using 100% compression. However while this creates a blocky image it does not affect the drawing time. I now think this is because the number of pixels that get rendered is not changed by this

I tried reducing the color palette to 256 colors. This makes the size smaller since it uses less bytes per pixel but does not seem to affect drawing on screen. I had thought that reducing the bytes per pixel GDI+ has to handle might save some time but it is not enough for me to see so far.

So am I wasting my time looking at compression and palette?

I assume that time taken will be affected by the number of pixels to be drawn (width x height) and I have resized the image to match the pixel size as displayed on screen. I think this is the one thing that does have an effect....

I have looked at how to stop autoscaling of the image - does my resize stop that or can the image still be autoscaled when it is rendered?

I am wondering if I can replace the DrawImage call with something using p/Invoke or other API call (which I admit I don't really understand).

Community
  • 1
  • 1
ScruffyDuck
  • 2,606
  • 3
  • 34
  • 50

1 Answers1

1

You could use the Bitblt P/Invoke, which copies image data directly. It does require some initialisation to convert the image data to something the display device understands, but this copy operation is lightning fast. If you would like to know what exactly is happening in DrawImage btw, use a tool like ILSpy or Reflector.NET to inspect the method.

See BitBlt code not working for an example. For some information about Bitblt see http://www.codeproject.com/KB/GDI-plus/flicker_free.aspx.

Community
  • 1
  • 1
C.Evenhuis
  • 25,996
  • 2
  • 58
  • 72
  • It is bizarre that in investigating how to implement BitBlt in the graphics engine I stumbled across a Property called RenderQuality that is associated with the deviceContext. By applying LowQuality while rendering images and HighQuality for everything else my performance issues appear to have gone. So it seems that the journey on this one may be over at last..... – ScruffyDuck Jul 11 '11 at 21:27