locked
DrawImage performance RRS feed

  • Question

  • User-1385434563 posted
    I am experiencing difficulties with the TIFF raster images using the overloaded drawimage method in a map web service written using VB, ASP.NET and webmatrix: objgraphic.DrawImage(origbitmap,destinationRect,sourceRect,GraphicsUnit.Pixel) It seems slow and often fails running under IIS - with the fatal application event - aspnet_wp.exe (PID: 1312) was recycled because memory consumption exceeded the 143 MB (60 percent of available RAM). Are there any third party alternatives to DrawImage which are faster and more reliable? Tom
    Wednesday, April 7, 2004 7:24 AM

All replies

  • User1951538761 posted
    Are you by any chance using huge TIFF images? How large are they (in both bytes and pixel dimentions)? Can you determine the difference in RAM usage between IIS running "bare", and when one user hits your app, versus when N users hit it, etc? Avi
    Tuesday, April 20, 2004 7:31 PM
  • User-1385434563 posted
    Not particulary - 5MB colour max, but problem is mainly with 0.5MB mono class 4 Tiffs. No difference between bare and users - it is when this file is loaded the memory usage zooms up. Obviously the more users - the worse the problem. I've managed to chop up the files into quadrants - helped a bit but still unstable. Tom
    Tuesday, May 18, 2004 8:27 AM
  • User1951538761 posted
    Tom - is it possible for you to repro this in a Winforms app?
    Tuesday, May 25, 2004 8:28 PM
  • User1951538761 posted
    Tom - another update. I've found an expert on this part of the framework who can help you, but he's out for the rest of the week. He will join the thread next week. Meanwhile, you might want to see if you can repro this using Winforms.
    Wednesday, May 26, 2004 7:48 PM
  • User-1385434563 posted
    Just got it running in Winforms, it still seems slow but need to do some better benchmarking - will report next week. Tom
    Friday, May 28, 2004 11:05 AM
  • User-1385434563 posted
    OK done some proper .NET benchmarking now. The time to generate an identical sized image from the files was virtually the same for windows and web apps. Details as follows: File A, 15.6MB, TIFF, 8 bit color, 4000 x 4000 pixels, uncompressed, 1.5 secs on windows and 1.7 secs on web application. File B, 0.5MB, TIFF, Mono G4 compression, 7874 x 7874 pixels, 9.1 secs on windows and 9.2 secs on web application. Both these files load virtually instanteously in Microsoft Office Document Imaging. Conclusion - native .NET framework v1.1 is relatively slow with raster images and is v poor with Mono G4 compression. Is Whidbey going to improve this? We want to stay totally within the framework and not use 3rd party add-ins. Comments?
    Wednesday, June 2, 2004 6:31 AM
  • User1951538761 posted
    Good stuff, Tom; thanks for the test results. I've passed this on to a guy who owns bits of this code, and he'll get onto this thread soon. He's currently working on some urgent Whidbey stuff, which is why it's been taking a while. Stay tuned.
    Wednesday, June 2, 2004 8:06 PM
  • User1951538761 posted
    Ok Tom - really sorry for the long delay. Here's the information that a couple of devs on the team have suggested: The images you're dealing with are small when compressed, but when they are decompressed into RAM in their raw format, their size (in pixels) just makes them huge. For example: Decompression (even at 8bpp) File B, 0.5MB, TIFF, Mono G4 compression, 7874 x 7874 pixels is 62MB. The theory is that the Office App you're comparing against might be using a newer version of the code that handles this better. I'm going to email your hotmail account and send you my direct email address. If you would zip up your benchmark project and send it over, we'll try to repro the issue with the new code versus the old code. Does that work for you?
    Wednesday, June 16, 2004 12:46 PM