Rectangle movement is very slow on high resolution image

Question

4.33/5 (3 votes)

See more:

I have an application inwhich an image is loaded in imagebox. Then an small rectangle is created and moved to select and zoom selected area. But when I move the rectangle it is responding very slow for high resolution image (1000 ppi).

Any suggestion is welcome and appreciated.

Posted 10-Mar-11 23:21pm

SUNILHNBGU

Add a Solution

Comments

Albin Abel 11-Mar-11 7:24am

What is your rectangle object. How you are moving it. Without seeing your coding snippets it is difficult to guess the problem. Is it WPF?

3 solutions

Solution 1

To make your application always responsive even for big images, I suggest you reduce the resolution of the image displayed to the user (and keep the original one in memory). For example:
http://www.dreamincode.net/code/snippet1986.htm[^]

Modify that code to never exceed a maximum size.

Posted 11-Mar-11 1:49am

Olivier Levrey

Updated 11-Mar-11 1:50am

v2

Comments

Sergey Alexandrovich Kryukov 11-Mar-11 13:23pm

Olivier, this can be against requirements. In fact, the problem is not so difficult and can be completely eliminated for some fast operations like the one described. It depends on other requirements though. I use to solve this problem. Even when maximum worse-case time was considerable, fast operations did not depend on the image. The key is not using Image Box and proper cashing. Please see my Answer.
(I didn't vote this time.)
--SA

Olivier Levrey 11-Mar-11 15:32pm

Why not using PictureBox? I am used to this problem as well and I often use double-buffering or kind of equivalent like I suggested in my answer.

Sergey Alexandrovich Kryukov 11-Mar-11 22:21pm

PictireBox is not designed for doing anything dynamically and in this case would merely sit in the middle adding no value. It is designed to simplify programming and support if the purpose is just to put some image. Control also has double buffering as an option (should be used), but it does not replace cashing I use. (It is just to reduce flicker as you know.) Anything which serves no purpose is a direct or indirect performance hit, kind of.
--SA

Olivier Levrey 12-Mar-11 5:12am

Ok for PictureBox, I was just curious about it.
However I do not agree about double-buffering. It is used to avoid flickering, it is true, but it is also efficient to improve performance. Drawing directly to the screen using the Graphics argument from the Paint handler is always slow. If you do your drawings in a memory buffer and once it is ready print it to the screen (so you would you use the Graphics argument from the Paint handler only once for a bit-block transfer), then the performances are improved.

Sergey Alexandrovich Kryukov 12-Mar-11 17:43pm

Yes, absolutely, if you paint on picture box, but this is redundant operation; if you render just on control, you do all rendering in WM_PAINT anyway. Double buffering is actually extra CPU time in this way but needed to remove flicker. Again, using picture box does not help here.
--SA

Solution 2

I suggest to increase step of increment in mouse.move event, or parametrize it in function of current resolution reached ...

i.e.

C#

private void mouseMove(object sender, MouseEventArgs e)
{
   static int lastx,lasty;
   int delta = 100;
   if (abs(lastx-e.X)>delta || abs(lasty-e.y)>delta)>
     {
        lastx=e.X;
        lasty=e.Y;
        ...
        "your zoom box code"
        ...
     }

}

Posted 11-Mar-11 1:57am

Piccadilly Yum Yum

Updated 11-Mar-11 2:21am

v4

Comments

Sergey Alexandrovich Kryukov 11-Mar-11 13:20pm

It does not help much and can be against requirements.
--SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-03-11T07:20:00

Solution 3

This delay should not happen. I had this problem and made sure that any image rendering on top of you detail-rich graphics is constant, no matter what the image is.

First of all, let me tell you the resolution is PPI has nothing to do with the problem. What really matter is the part of the image is rendered on screen how much time your rendering takes. When you move you rectangle over you image, some part of your image is masked, some is showing up. You need to invalidate part of the image which trigger the paint event and takes as much time as it does. The following should help:

1) Do not paint on image box. Paint on some control. You can implements pan/zoom, etc. When changing anything on top which require invalidation, use Control.Invalidate with a parameter (region or rectangle) to minimize invalidated area.

2) Classify your operations into faster and slower and introduce cashed image. It should cash only what is currently shown on your screen at the time. If your image is much bigger, cash 2-3 time more (in each direction) to make scrolling in neighbor position fast. On "slow" operation, such as scrolling away, re-write cash and re-render from source. For "fast" operations, such as your rectangle motion, render from cash only. Introduce the operation of cash invalidation.

3) This advice is alternative: switch to WPF. Many your problems are already resolved, and performance is generally much better if you use things correctly.

—SA

Posted 11-Mar-11 7:20am

Sergey Alexandrovich Kryukov

Comments

Espen Harlinn 11-Mar-11 14:02pm

Good suggestions, my 5

Sergey Alexandrovich Kryukov 11-Mar-11 19:25pm

Thank you, Espen,
--SA

Olivier Levrey 11-Mar-11 15:34pm

Cashing the image is quite I suggested. You advised to cash hidden parts of the image even though OP didn't say a word about scrolling, did he?

Sergey Alexandrovich Kryukov 11-Mar-11 19:31pm

I don't know about scrolling, I only assume there is a lot of graphical data. If all graphical data fits the maximum available screen or less, this is only a special case of a more general case I consider. What works for more general case will work in more special case at the same speed or better. The general case is: you have big and complex constant (or almost constant image) mapped in screen; and the rendering from original data is relatively slow (I don't even consider the speed of one-to-one rendering of pixels on screen as it is very fast (unless someone uses PutPixel or other stupid techniques)). Image is the constant (or rarely changed, for example, showing different sets of layers), but mapping may change. I consider this just to address as general case as possible. I use scrolling only as an example of the considerable re-rendering from original data due to 100% cash-miss.
--SA

SUNILHNBGU 14-Mar-11 8:51am

Thanks SAKryukov, Can you please review the sample project, and kindly suggest me with the code of this sample project. link: http://www.codeproject.com/KB/graphics/YLScsZoom.aspx.

Sergey Alexandrovich Kryukov 14-Mar-11 17:53pm

This is not your project. So, 1) how much is it related to yours, 2) what's wrong with this project, why could be a sample for yours?
--SA

Olivier Levrey 11-Mar-11 15:42pm

By the way, are you sure of your first sentence? The bigger the image, the longer it should take to draw. I may agree if you don't use any interpolation to draw it, but if using bilinear or bicubic then size should matter.

Sergey Alexandrovich Kryukov 11-Mar-11 19:24pm

I'm 100% sure. The key is "slow" and "fast" operations. Slow operations takes some time, let's say, proportional to the amount of pixels (square of rectangle), because you miss 100% of cash and ultimately re-render 100% of visible screen and 100% of cash. For "fast" operation, 100% of image is re-rendered from cash, and this is not all the image but invalidated region. But this invalidated region is defined by the rectangle moving in top and the step. So the performance depends on the rectangle size and step, but does not depend on the picture to be re-rendered.
Do you see the point?
--SA

Olivier Levrey 12-Mar-11 5:07am

Yes I see. I didn't understand the fast operation was relative to the invalidated region.

Sergey Alexandrovich Kryukov 12-Mar-11 17:40pm

Thank you.

SUNILHNBGU 14-Mar-11 8:42am

Hey Guys,
Thanks for help and a great discussion. I have found a sample project on this site and my requirement is almost same as this project. But the problem is same for this sample project.
here is the link: http://www.codeproject.com/KB/graphics/YLScsZoom.aspx[^]
Thanks SAKryukov, for your valuable suggestion. Can you please suggest me the exact point on the basis of the code of this sample project, since I do not have much more experience with .NET.
Your help is really reruired.

Thanks Guyz.....

Sergey Alexandrovich Kryukov 14-Mar-11 17:50pm

You're welcome.
I cannot give you "exact point" simply because your information is limited. You need to ask a new question, name it "Performance problem in rendering of ...." and explain what are you rendering.
More exactly, I'll need to know: the nature of original data to be presented (vector graphics or not, semantic model, nature of data type/format, text form of not, parser/API used to get data, etc.), the volume of data and typical object size in pixels, by the order of magnitude (if zooming is involved, the size at maximum reasonable zoom), other relevant detail, the _small_ code sample if possible.
Also, be prepared to consider WPF where most problems are already solved.
I'm almost 100% sure you can obtain reasonable performance even is you have a severe bottleneck. The key not acceleration of things but running slow part rarely, based in data redundancy (cashing is performance-oriented feature based on data redundancy).
If you post a new question, feel free to notify me immediately by replying to this commend and giving me the reference to the new Question.
Good luck,
--SA

SUNILHNBGU 15-Mar-11 8:30am

Thanks SAKryukov,

I have posted a new question regarding the performance. I have mentioned sample code of this application. It may help to detect actual problem with code. please review the code and suggest what is the right way to implement.
http://www.codeproject.com/Questions/168949/How-to-solve-performance-problem-in-rendering-Draw.aspx
Thanks.....

Sergey Alexandrovich Kryukov 15-Mar-11 11:45am

OK, I answered, but you did not provide enough information. Please see.
--SA