Slow For-Loop (Picture Data Access)

[hufaunder]

I think common sense and usability has to come into play too. Lots of
properties are backed by unmanaged resources. Control.Text if it's not
cached, Control.ModifierKeys, TreeNode.Bounds, most of the interesting
properties on WebBrowser, etc. Check out the work FileInfo.Directory
does. If anything, the problem with Image is that it doesn't cache the
width and height, and have some kind of internal observer set up with
the GDI+ side to refresh them if necessary. There's a risk that you end
up with the Java-itis of 'GetFoo().GetBar().GetBaz()' versus
'Foo.Bar.Baz'.

In many ways, I feel that if you're doing something based on
Width*Height of an image, you're in a state of sin anyway - that's going
to be in the millions for many common images. Most usable image
manipulation code I've seen works with the scanlines directly, often in
assembler tuned for the processor where possible.

Berry, if you do have a solution that does not require me to loop
through all the values that would be greatly appreciated. I was hoping
I could combine the 16bit grayscale image format with some lookup table
but that does not seem possible. Then the background process will do
all of this for me (hopefully with optimized code).

I don't see why Width*Height should be a sin. I do get the scanline and
then go from there (imageWidth%4=0, always).

As long as I get satisfactory performance I am not going to write any
assembler. Even if I see a bottleneck I first try other optimizations
before reverting to assembler. Plus there are some good libs out there
(ipp, etc) that are quite optimized.