How to speed up graphical application?

First of all, always release the graphics objects you use. They use lots of resources, and you shouldn't wait for the garbage collector to clean it up.

Then, you should never use Properties of objects directly. I was writing a video server once, and was continously checking Bitmap.Width. Then I used a profiler to see what caused my code to be so slow, and you can better store such lots-requested properties into local (stack) variables.

Then, you should never use Properties of objects directly. I was writing a video server once, and was continously checking Bitmap.Width. Then I used a profiler to see what caused my code to be so slow, and you can better store such lots-requested properties into local (stack) variables.
I assume you were using a profiler that checks the time spent per line of code. Those are (unfortunately) hideously inaccurate. Properties are fast, and in quite a few cases can be inlined when optimisations are enabled meaning they should be just as fast as accessing the member directly. If property accesses are really making your program 'slow', then it's because the property is doing a lot more than just returning a value.

My application is some what like paint and other image manipulation application so here i am working on bitmap for operation like rotation, brightness, contrast and drawing lines, curves, rectangles on the bitmap. and every times when i draw shape on the bitmap i am refreshing the it. may it is the cause of slowness of application? please guide me.

Which is the case with Bitmap.Width. It causes the application to run really slow. It's a lot better to get it once and store it another place.
What i'm saying is that if you look at a line-based profiler, it will show properties as taking a large amount of time whereas in actual fact in normal runtime, they don't. So don't rely on a line-based profiler.

The .Width property may be slow (i don't know) but in general, 99% of the time, you should be fine using properties. That's why i strongly disagree with the blanket statement "you should never use Properties of objects directly". It's just plain misleading. I really doubt bitmap.width is as slow as you say, have you tried writing a for loop and running it 10,000,00 times store bitmap.width in a local variable and compare it to the time taken to just set that local variable = 5? That'd be a better test than a profiler.

Also, what you could try doing to speed up your app is to disable redraws when you are physically updating the object. Certain controls have a BeginUpdate and EndUpdate method which you can call which disables repainting while you perform actions. That might be helpful in this case.

And, for example, the Count attribute of a collection?
for (int i = 0; i < _data.Count; i++)

and

int count = _data.Count;
for (int i = 0; i < count; i++)

No difference.

We all know that foreach is slow, but will there be a difference between
Well, it'll be a little slower in certain cases, true. But not substantially slower, in other cases it'll be just as fast. foreach was slower in .NET 1.0, but it was much improved in 1.1 and hasn't 'slowed down' since.

The other common thing to quote is that you should use myString.Length == 0 rather than mystring == string.Empty. Technically, checking length is faster, but the difference is minimal.

You may be familiar with the string.IsNullOrEmpty method. You may think that it is slower than writing the following code as it involves an extra method call:

if(mystring == null || mystring.Length == 0)

But it is *not* so slow that i'd recommend you write the above snippet as opposed to using String.IsNullOrEmpty(). If the JIT inlines the method call (which it will do in non-debug code) it should be just as fast but more readable.

The problem with performance is that people get hung up on saving 70% CPU time on a method that gets called a dozen or two times a second whereas if they changed an algorithm in their code which was called several million times a second which saved 1% CPU time per call, they'd speed their code up so much more.

What i'm saying is that if you look at a line-based profiler, it will show properties as taking a large amount of time whereas in actual fact in normal runtime, they don't. So don't rely on a line-based profiler.

The .Width property may be slow (i don't know) but in general, 99% of the time, you should be fine using properties. That's why i strongly disagree with the blanket statement "you should never use Properties of objects directly". It's just plain misleading. I really doubt bitmap.width is as slow as you say, have you tried writing a for loop and running it 10,000,00 times store bitmap.width in a local variable and compare it to the time taken to just set that local variable = 5? That'd be a better test than a profiler.

Yes. I made a screensaver application, and couldn't figure out why everything was running so slow, until I tried storing it in a local variable.
But yes, "you should never use properties of objects directly" is pretty misleading, but you should be aware that some times properties do more than just return a value (which, in my opinion, is all that they should do), which slows down your program a lot.

As told by Bornish: if you are drawing a lot, you should consider using DirectX or OpenGL to draw your stuff.

Also, double-buffering can be a nice feature. Draw your image in memory, and as soon as you are ready, display it on the screen. Then you can use the buffer you just made invisible to draw the new frame. This prevents flickering etc.

Also, reduce the number of frames. You don't have to make it to 70 fps. 25 is more than enough (American television is even 23,9 (or something like that), European is 25).

as far as i know page flipping only works in fullscreen mode...you can have as many windows you need using page flipping! Double-buffering, overlay with transparency (for rendering rubberbanding / dynamics), display lists and array passing of primitives and colors... all improve dramatically the speed of a graphical app.
Regards,

[QUOTE=Mutant_FruitYou may be familiar with the string.IsNullOrEmpty method. You may think that it is slower than writing the following code as it involves an extra method call:
[/QUOTE]

A common misconception. Many Property accessors, and other "simple" Method calls are optimized out of existance (ie Inlined) by the JIT Compiler.

A common misconception. Many Property accessors, and other "simple" Method calls are optimized out of existance (ie Inlined) by the JIT Compiler.
Please read the rest of my post. I made that exact comment.