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.
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:Oe**************@TK2MSFTNGP05.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com
"Alexander Vasilevsky" <ma**@alvas.netwrote in message
news:fk**********@behemoth.volia.net...
>What paint faster than Graphics.Draw?
http://www.alvas.net - Audio tools for C# and VB.Net developers +
Christmas discount
