What paint faster than Graphics.Draw?

[Alexander Vasilevsky]

What paint faster than Graphics.Draw?

http://www.alvas.net - Audio tools for C# and VB.Net developers + Christmas
discount

 

[Nicholas Paldino [.NET/C# MVP]]

It's not really a matter of what paints faster. You really have little
choice (other than using the API directly on the device context handle, in
which case, I don't know that it will do much for you).

It's usually more a matter of how you are using the Graphics instance.
Are you double buffering? Are you repainting the entire area when only a
portion of it needs to be repainted?

What is it that you are doing which is not fast enough?

 

[Norman Diamond]

I agree with the first part of that answer. Draw is one case where the .Net
Framework really stands out: calls to .Net Draw methods can be coded 50
times faster than calls to Win32 APIs, but they execute 50 times slower.
(Well, experts could code calls to Win32 APIs almost as fast as calls to
..Net Draw methods.) StretchBlt is likely to be useful.

I don't understand how it would help to use double buffering. That could
solve flashing and tearing but not speed.

It's not really a matter of what paints faster. You really have little
choice (other than using the API directly on the device context handle, in
which case, I don't know that it will do much for you).

It's usually more a matter of how you are using the Graphics instance.
Are you double buffering? Are you repainting the entire area when only a
portion of it needs to be repainted?

What is it that you are doing which is not fast enough?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What paint faster than Graphics.Draw?

http://www.alvas.net - Audio tools for C# and VB.Net developers +
Christmas discount

 

[Barry Kelly]

I don't understand how it would help to use double buffering. That could
solve flashing and tearing but not speed.

Not exactly double-buffering, but using a back buffer can help to cache
the representation of a complex end-result image.

It's not really a matter of what paints faster. You really have little
choice (other than using the API directly on the device context handle, in
which case, I don't know that it will do much for you).

It's usually more a matter of how you are using the Graphics instance.
Are you double buffering? Are you repainting the entire area when only a
portion of it needs to be repainted?

What is it that you are doing which is not fast enough?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

What paint faster than Graphics.Draw?

http://www.alvas.net - Audio tools for C# and VB.Net developers +
Christmas discount

-- Barry