Graphics/Image Conundrum

[bullshark]

I have a C# application that manipulates images. The application provides
the ability to pan around the images. Normally you can "grab" the image
and move it around and it moves in real time with the mouse cursor.

There is very low friction. It slides easily.

My problem is that with larger images, it just turns to mud.
Refreshing the image, or re-drawing a screenful take so long that
trying to pan the image results in jumpy, jerky movements.

There is very high friction. It is sticky.

"Larger" images are on the order of 5000 x 10000 color jpg.

I am viewing a rectangle of the original image with no scaling
and drawing the image in OnPaint. It's all pretty standard stuff and
seems to be unresponsive to double buffering on or off.

It won't do "Big" Images at all. It just chokes trying to Image.FromFile.
I have gigaram and plenty of swap and I just don't understand why it fails
on images with a footprint over about 1.5 gig (l*w*colorbytes). Is GDI limited
to signed 32 address space?

*Interestingly*, when I single step somewhere (anywhere) in the debugger and
then continue (f5), the image will start moving easily and smoothly, of it's
own accord. This really bugs me. If the debugger can set some condition that
makes this stuff run well, then I should be able to do it too. Am I doing something
wrong? What does the debugger do to the graphics objects or memory when at
breakpoints?

The general logic
o uses onMouseMove/Down/Up to track drags of the image
o uses DrawImage( Image,drawRect,ImgRect,GraphicsUnit.Pixel) in OnPaint
o draws scale=1:1
o use double buffering (on/off doesn't matter for purposes of slowdown)
o disposes of any created graphic objects as soon as they're not needed

I am looking forward to your suggestions,

bullshark

 

[Willy Denoyette [MVP]]

It won't do "Big" Images at all. It just chokes trying to Image.FromFile.
I have gigaram and plenty of swap and I just don't understand why it fails
on images with a footprint over about 1.5 gig (l*w*colorbytes). Is GDI
limited
to signed 32 address space?

Yes, just like any other application on 32 bit Windows. Moreover you said
1.5 Gig, this is nearly the total free heap space in your process (and this
isn't even contigious, which is a requirement for byte arrays) , so I'm
pretty sure the system did started paging, No supprise that the painting is
jerkey.

Willy.

 

[bullshark]

Yes, just like any other application on 32 bit Windows.

Graphics is not an application per se, but its good to know anyway.
But that amount(1.5 gig) was a failure. DotNet can't load the image.

The images that are "sticky" are much, much smaller. On the order of 150 meg.

No supprise that the painting is jerkey.

So why, if paging is the problem, and that's what makes it jerk, then why
does stopping with a debugger and then resuming (F5), result in smooth,
jerk free operation?

That's the main reason I posted. If it runs fast (just like "normal")after
yielding to a breakpoint.

What does the debugger do, and how can I do it too?

regards,

bullshark