|
|
You're in the
dotnet drawing api
group:Any hope for decent performance of System.Drawing
dotnet drawing api:
Hi,
I am writing a realtime scientific graphing library for use in a=20 Windows.Forms application. I am using all the usual tricks to get=20 decent performance, yet the performance is still less than optimal. It=20 is ok for graphs that update about once per second, but I would like=20 to the graphs animated in real time so that they look more like an=20 analog oscilloscope. The problem as I understand it is that System.Drawing is not hardware=20 accelerated when using antialiasing or alpha blending. I just wrote a=20 small test program under Vista, and it is still outrageously slow.=20 Maybe I expect too much, but on a 2 GHz Core Duo machine with an Aero=20 compatible graphics card, any reasonable amount of drawing should be=20 done more or less instantaneously. I would love to use the new WPF stuff, but the problem is that the=20 companies using our software (aerospace) are quite conservative. Some=20 of them are just now doing the switch from NT4.0 to Win2K. So we will=20 have to support Win2K for a long time to come. Is there any hope that System.Drawing will get hardware acceleration=20 in the forseeable future, or will I have to implement a vector drawing=20 framework manually under DirectX to get decent performance under=20 Win2K? As you can probably imagine, I would rather like to avoid=20 that. cheers R=FCdiger Klaehn
On Jan 29, 12:07 pm, "Bob Powell [MVP]"
[quoted text, click to view] <bob@_spamkiller_bobpowell.net> wrote: Sad to hear that. Since the WPF drawing model is a superset of the GDI> The chances of improvements to GDI+ are somewhere between really, really > slim and none whatsoever. > + drawing model it should be possible to write a bridge that translates GDI+ drawnig commands to WPF commands. Might be a bit complex because WPF uses a retained model. But definitely doable. I guess that microsoft is not interested in people that still use Win2K :-( [quoted text, click to view] > I work in a bank, another conservative institution, and I feel confident Yes. It did not blow me away either. But I figured that I probably did > that I can persuade them to use the .NET 3.0 runtime on their XP systems > to deliver better performance for realtime applications. > > Even so, despite the fact that there are performance increases using WPF > and a decent graphics card, I have not, I'm afraid, been totally blown > away by the performance I've seen. > something wrong (I tried overriding OnRender and using a DrawingVisual). But at least with WPF microsoft has done a long term commitment, so I guess we can expect some improvements in this area. [quoted text, click to view] > There is no substitute for good programming. In the particular application I have in mind, there are no shortcuts > that can be taken. I already use some quite clever data structures. But the fact remains that I have to draw a few thousand antialiased lines >20 times per second. And it seems that System.Drawing is not up to the task. I have not yet given up on WPF, but since it is not compatible to Win2k I may have to use DirectX anyway. Using DirectX directly instead of WPF or System.Drawing is not good programming. It is a low level kludge that should not be necessary. But I guess I will have to do it if I want decent performance. A modern computer with a modern graphics card can draw several hundred thousand polygons at 60FPS. So it should be possible to draw a few thousand lines at 20FPS!
Hello Rüdiger Klaehn,
How big are your graphs in terms of pixel width and height? How lines are modified per frame? We seem to be able to draw a few thousand lines at 20 FPS. We were able to get about 30 FPS on a low end CPU drawing a 10K point anti-aliased particle system using about 600x600 pixels, purely with managed code and no pointers. Each particle is a 5 pixels wide. This has little to do with GDI+, we rendered directly into a pixel buffer, but it was a GDI+ Bitmap and we used the Bitmap to render the buffer. On a core duo it is faster. I can email the code if you wish. If you draw lots of lines you may need to use a single GraphicsPath with disjoint lines. That is much faster than separate draw line calls. Anyone hoping WPF will make complex graphics applications faster is in for a rude awakening... WPF provides no immediate mode API. There are software rendering APIs faster than GDI+. Anti-grain, for example. You may use them to render into a GDI+ or GDI bitmap. Otherwise you need DirectX and it is a mess trying to build a decent 2D API over that. Regards, Frank Hileman check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio graphics editor [quoted text, click to view] "Rüdiger Klaehn" <rudi@lambda-computing.com> wrote in message Hi,news:1169999820.592650.117340@v45g2000cwv.googlegroups.com... I am writing a realtime scientific graphing library for use in a Windows.Forms application. I am using all the usual tricks to get decent performance, yet the performance is still less than optimal. It is ok for graphs that update about once per second, but I would like to the graphs animated in real time so that they look more like an analog oscilloscope. The problem as I understand it is that System.Drawing is not hardware accelerated when using antialiasing or alpha blending. I just wrote a small test program under Vista, and it is still outrageously slow. Maybe I expect too much, but on a 2 GHz Core Duo machine with an Aero compatible graphics card, any reasonable amount of drawing should be done more or less instantaneously. I would love to use the new WPF stuff, but the problem is that the companies using our software (aerospace) are quite conservative. Some of them are just now doing the switch from NT4.0 to Win2K. So we will have to support Win2K for a long time to come. Is there any hope that System.Drawing will get hardware acceleration in the forseeable future, or will I have to implement a vector drawing framework manually under DirectX to get decent performance under Win2K? As you can probably imagine, I would rather like to avoid that. cheers Rüdiger Klaehn
The chances of improvements to GDI+ are somewhere between really, really
slim and none whatsoever. I work in a bank, another conservative institution, and I feel confident that I can persuade them to use the .NET 3.0 runtime on their XP systems to deliver better performance for realtime applications. Even so, despite the fact that there are performance increases using WPF and a decent graphics card, I have not, I'm afraid, been totally blown away by the performance I've seen. There is no substitute for good programming. -- Bob Powell [MVP] Visual C#, System.Drawing Ramuseco Limited .NET consulting http://www.ramuseco.com Find great Windows Forms articles in Windows Forms Tips and Tricks http://www.bobpowell.net/tipstricks.htm Answer those GDI+ questions with the GDI+ FAQ http://www.bobpowell.net/faqmain.htm All new articles provide code in C# and VB.NET. Subscribe to the RSS feeds provided and never miss a new article. [quoted text, click to view] Rüdiger Klaehn wrote:
> Hi, > > I am writing a realtime scientific graphing library for use in a > Windows.Forms application. I am using all the usual tricks to get > decent performance, yet the performance is still less than optimal. It > is ok for graphs that update about once per second, but I would like > to the graphs animated in real time so that they look more like an > analog oscilloscope. > > The problem as I understand it is that System.Drawing is not hardware > accelerated when using antialiasing or alpha blending. I just wrote a > small test program under Vista, and it is still outrageously slow. > Maybe I expect too much, but on a 2 GHz Core Duo machine with an Aero > compatible graphics card, any reasonable amount of drawing should be > done more or less instantaneously. > > I would love to use the new WPF stuff, but the problem is that the > companies using our software (aerospace) are quite conservative. Some > of them are just now doing the switch from NT4.0 to Win2K. So we will > have to support Win2K for a long time to come. > > Is there any hope that System.Drawing will get hardware acceleration > in the forseeable future, or will I have to implement a vector drawing > framework manually under DirectX to get decent performance under > Win2K? As you can probably imagine, I would rather like to avoid > that. > > cheers > > Rüdiger Klaehn
Hi
The big difference is where everything is processed: System.Drawing uses the CPU whereas DirectX uses the GPU. However, if DirectX cannot be used, you still can get quite an increase in performance if you draw the picture before showing it (like DirectX's backbuffer does). btw: I really do not see why DirectX should not be good programming. Yours, Lukas Cavigelli http://www.cavigelli.net -- http://www.cavigelli.net "Rüdiger Klaehn" <rudi@lambda-computing.com> schrieb im Newsbeitrag news:1170075836.840897.105100@k78g2000cwa.googlegroups.com... [quoted text, click to view] > On Jan 29, 12:07 pm, "Bob Powell [MVP]"
> <bob@_spamkiller_bobpowell.net> wrote: >> The chances of improvements to GDI+ are somewhere between really, really >> slim and none whatsoever. >> > Sad to hear that. Since the WPF drawing model is a superset of the GDI > + drawing model it should be possible to write a bridge that > translates GDI+ drawnig commands to WPF commands. Might be a bit > complex because WPF uses a retained model. But definitely doable. I > guess that microsoft is not interested in people that still use > Win2K :-( > >> I work in a bank, another conservative institution, and I feel confident >> that I can persuade them to use the .NET 3.0 runtime on their XP systems >> to deliver better performance for realtime applications. >> >> Even so, despite the fact that there are performance increases using WPF >> and a decent graphics card, I have not, I'm afraid, been totally blown >> away by the performance I've seen. >> > Yes. It did not blow me away either. But I figured that I probably did > something wrong (I tried overriding OnRender and using a > DrawingVisual). > > But at least with WPF microsoft has done a long term commitment, so I > guess we can expect some improvements in this area. > >> There is no substitute for good programming. >> > In the particular application I have in mind, there are no shortcuts > that can be taken. I already use some quite clever data structures. > But the fact remains that I have to draw a few thousand antialiased > lines >20 times per second. And it seems that System.Drawing is not up > to the task. I have not yet given up on WPF, but since it is not > compatible to Win2k I may have to use DirectX anyway. > > Using DirectX directly instead of WPF or System.Drawing is not good > programming. It is a low level kludge that should not be necessary. > But I guess I will have to do it if I want decent performance. A > modern computer with a modern graphics card can draw several hundred > thousand polygons at 60FPS. So it should be possible to draw a few > thousand lines at 20FPS! >
On Jan 29, 6:52 pm, "Frank Hileman"
[quoted text, click to view] <frank...@no.spamming.prodigesoftware.com> wrote: They can get quite large. I have seen people use dual screen setups> Hello R=FCdiger Klaehn, > > How big are your graphs in terms of pixel width and height? How lines are > modified per frame? We seem to be able to draw a few thousand lines at 20 > FPS. > with each screen having 1600x1200 pixels with our application. Even that was not enough for them, so they used a bigger MDI client area. [quoted text, click to view] > We were able to get about 30 FPS on a low end CPU drawing a 10K point Thanks for the offer. I would love to see the code. Any piece of high> anti-aliased particle system using about 600x600 pixels, purely with mana= ged > code and no pointers. Each particle is a 5 pixels wide. This has little to > do with GDI+, we rendered directly into a pixel buffer, but it was a GDI+ > Bitmap and we used the Bitmap to render the buffer. On a core duo it is > faster. I can email the code if you wish. > performance code contains something to learn from even if it is not directly applicable to the problem at hand. [quoted text, click to view] > If you draw lots of lines you may need to use a single GraphicsPath with Thanks. I will try that. Might be quite complicated in my case since I> disjoint lines. That is much faster than separate draw line calls. > would first have to sort the drawing commands by the used pen. It does seem to make a significant difference in a small test program though. [quoted text, click to view] > Anyone hoping WPF will make complex graphics applications faster is in fo= Somewhere in the framework there has to be a method to convert a 2Dr a > rude awakening... WPF provides no immediate mode API. > path into a 3D mesh. There has to be a way to tap into this method without using all the WPF overhead. WPF seems to be more designed for ease of use than for performance. It uses mutable data structures way too much for my liking. But as a fan of functional programming I only use mutable data structures when absolutely necessary. And there seems to be a significant overhead for the change notification. Weak referenced event handlers. Yukk. Anyway, there has to be a way to get access to the lower level stuff. I ordered some books about WPF, but they have not arrived yet. [quoted text, click to view] > There are software rendering APIs faster than GDI+. Anti-grain, for examp= Anti-Grain looks nice. But it is GPL, so I can not use it. Did you tryle. > You may use them to render into a GDI+ or GDI bitmap. Otherwise you need > DirectX and it is a mess trying to build a decent 2D API over that. > doing a DirectX wrapper? I did some small experiments. You can get really good performance, but especially handling the different graphics card capabilities smoothly is a major PITA. By the way: Thanks for your very informative posting. You should get a MVP for GDI+. cheers R=FCdiger
"Nip" <admin@cavigelli.net> ha scritto nel messaggio
news:984664DA-8CCD-4F25-AE4A- [quoted text, click to view] > > btw: I really do not see why DirectX should not be good programming. > I'm a bit confused. If GDI+ has serious limits I think it should be declared as obsolete and someone (Microsoft) should provide a new graphic architecture. Or maybe GDI+ should simply be a DX wrapper to workaround all its limitations. If it is not so, I would aspect that HW producers will add a GDI+ support into their G-cards, and that the GDI+ library still grow freely.
[quoted text, click to view]
> If it is not so, I would aspect that HW producers will add a GDI+ support > into their G-cards, and that the GDI+ library still grow freely. I've only heard of one graphics card producing a hardware accelerator for GDI+. I don't recall which. In any case, GDI+ has been around for a while (Win2000 I believe) and if hardware makers haven't accelerated it by now, they likely won't ever. Especially considering Microsoft has all but abandoned it in favor of WPF. Thanks, Shawn
[quoted text, click to view]
>> I've only heard of one graphics card producing a hardware accelerator for >> GDI+. I don't recall which. In any case, GDI+ has been around for a >> while (Win2000 I believe) and if hardware makers haven't accelerated it >> by now, they likely won't ever. Especially considering Microsoft has all >> but abandoned it in favor of WPF. > > So GDI+ is obsolete... > We'll it'll be around for a while longer, especially considering System.Drawing is built upon it. They may still tweak the software performance aspect of it. It probly performs a heck of a lot better on 64-bit hardware due to the availability of the extra registers (any software will be in the same camp). But in terms of actual "improvements", the only real improvement one can make is with hardware acceleration. For some reason, GPU makers have always accelerated GDI but have chose not to with GDI+ (except for one). Ultimately, for that alone, I would consider it obsolete except the fact that System.Drawing uses it exclusively. Some have said that WPF isn't much better, but if that is Microsoft's direction, it likely will get better until there is another graphic technology for them to move onto. Since its built upon DirectX, it should be a bit faster. However, I don't know whether hardware makers themselves are accelerating WPF directly of if MS is doing it themselves because the GPU makers have no desire to. In any case, I've seen people get impressive performance characteristics with GDI+ but they had to use every "trick" in the book, straight out-of-the-box GDI+ can be painful slow. Thanks, Shawn
"Shawn B." <leabre@html.com> ha scritto nel messaggio
news:O16XOdjRHHA.5064@TK2MSFTNGP02.phx.gbl... [quoted text, click to view] > I've only heard of one graphics card producing a hardware accelerator for > GDI+. I don't recall which. In any case, GDI+ has been around for a > while (Win2000 I believe) and if hardware makers haven't accelerated it by > now, they likely won't ever. Especially considering Microsoft has all but > abandoned it in favor of WPF. So GDI+ is obsolete...
[quoted text, click to view]
"Shawn B." <leabre@html.com> wrote in message news:ukkCC0vRHHA.4060@TK2MSFTNGP03.phx.gbl... > Some have said that WPF isn't much better, but if that is Microsoft's > direction, it likely will get better until there is another graphic > technology for them to move onto. Since its built upon DirectX, it should > be a bit faster. However, I don't know whether hardware makers themselves > are accelerating WPF directly of if MS is doing it themselves because the > GPU makers have no desire to. How exactly can MS do the hardware acceleration themselves when they don't make the hardware? ;-) Michael
[quoted text, click to view]
>> Some have said that WPF isn't much better, but if that is Microsoft's >> direction, it likely will get better until there is another graphic >> technology for them to move onto. Since its built upon DirectX, it >> should be a bit faster. However, I don't know whether hardware makers >> themselves are accelerating WPF directly of if MS is doing it themselves >> because the GPU makers have no desire to. > > How exactly can MS do the hardware acceleration themselves when they don't > make the hardware? ;-) What I was aluding to is them simply using software algorithms themselves ontop of DirectX vs. just publishing interfaces that the hardware makers will accelerate in hardware. It still makes a difference to use software ontop of DirectX vs. not using directx at all, but I'd still rather see bonafide hardware acceleration. My nVidia 8800GTX has 128 steam processors that can be utilized for accelerating WPF/GDI+ very easily but I gather that the only real optimizations were going to get is software ontop of DirectX. GID+ isn't even build on top of any hardware accelerated layer so its still a step in the right direction. Thanks, Shawn
GDI+ is still supported however no improvements are expected.
WPF is the graphics architecture that will replace GDI+ when it becomes obsolete so MS _have_ provided an alternative that is definitely hardware accelerated. So far only Matrox have produced hardware accelerated graphics cards for GDI+. I had one and it was good however I took it out of the machine because I get a more realistic view of the real world when I use the software rendering. -- Bob Powell [MVP] Visual C#, System.Drawing Ramuseco Limited .NET consulting http://www.ramuseco.com Find great Windows Forms articles in Windows Forms Tips and Tricks http://www.bobpowell.net/tipstricks.htm Answer those GDI+ questions with the GDI+ FAQ http://www.bobpowell.net/faqmain.htm All new articles provide code in C# and VB.NET. Subscribe to the RSS feeds provided and never miss a new article. [quoted text, click to view] Fabio Z wrote:
> "Nip" <admin@cavigelli.net> ha scritto nel messaggio > news:984664DA-8CCD-4F25-AE4A- > >> btw: I really do not see why DirectX should not be good programming. >> > > I'm a bit confused. > If GDI+ has serious limits I think it should be declared as obsolete and > someone (Microsoft) should provide a new graphic architecture. > Or maybe GDI+ should simply be a DX wrapper to workaround all its > limitations. > > If it is not so, I would aspect that HW producers will add a GDI+ support > into their G-cards, and that the GDI+ library still grow freely. > >
[quoted text, click to view]
"Shawn B." <leabre@html.com> wrote in message news:O8wp7%23YSHHA.3428@TK2MSFTNGP04.phx.gbl... > What I was aluding to is them simply using software algorithms themselves > ontop of DirectX vs. just publishing interfaces that the hardware makers > will accelerate in hardware. It still makes a difference to use software > ontop of DirectX vs. not using directx at all, but I'd still rather see > bonafide hardware acceleration. > > My nVidia 8800GTX has 128 steam processors that can be utilized for > accelerating WPF/GDI+ very easily but I gather that the only real > optimizations were going to get is software ontop of DirectX. GID+ isn't > even build on top of any hardware accelerated layer so its still a step in > the right direction. I believe there is still some acceleration for GDI plus. If you've done a fresh install of windows without loading the graphics card drivers you'll know what a complete lack of acceleration is like - very slow. GDI+ benefits from many of the GDI acceleration still. Michael
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> ha scritto nel messaggio
news:uiel44WSHHA.4260@TK2MSFTNGP06.phx.gbl... [quoted text, click to view] > WPF is the graphics architecture that will replace GDI+ when it becomes > obsolete so MS _have_ provided an alternative that is definitely hardware > accelerated. So, if I develop graphic applications I should consider to abandone GDI+ (no longer supported, also if not "uficially" obsolete) for WPF. And I really don't like this: Microsoft announced GDI+ as the new generation of drawing framework for windows, and just some years later it is already old and not supported. This seems to me a real waste of time, experience and money.
"Michael C" <nospam@nospam.com> ha scritto nel messaggio news:eP8l%
[quoted text, click to view] > > That's computers for ya. :-) ???
[quoted text, click to view]
"Fabio" <znt.fabio@virgilio.it> wrote in message news:ew8v4xjSHHA.2212@TK2MSFTNGP02.phx.gbl... > So, if I develop graphic applications I should consider to abandone GDI+ > (no longer supported, also if not "uficially" obsolete) for WPF. > And I really don't like this: Microsoft announced GDI+ as the new > generation of drawing framework for windows, and just some years later it > is already old and not supported. > This seems to me a real waste of time, experience and money. That's computers for ya. :-) [quoted text, click to view] > >
[quoted text, click to view]
"Fabio" <znt.fabio@virgilio.it> wrote in message news:ue1vxokSHHA.4632@TK2MSFTNGP04.phx.gbl... > "Michael C" <nospam@nospam.com> ha scritto nel messaggio news:eP8l% >> >> That's computers for ya. :-) > > ??? Hey? [quoted text, click to view] > >
So what else is new? How about .NET Remoting vs WCF? Same exact deal.
Remoting was the Great New Thing in 2002, a scant five years ago. Sometimes the marketroid's desire for Something New to Push overcomes the understanding that APIs should be built for the long haul. This can take the form of churning platforms too quickly, or just introducing something that's not fully baked and doesn't stand the test of time. --Bob [quoted text, click to view] Fabio wrote:
> "Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> ha scritto nel messaggio > news:uiel44WSHHA.4260@TK2MSFTNGP06.phx.gbl... > >> WPF is the graphics architecture that will replace GDI+ when it becomes >> obsolete so MS _have_ provided an alternative that is definitely hardware >> accelerated. > > So, if I develop graphic applications I should consider to abandone GDI+ (no > longer supported, also if not "uficially" obsolete) for WPF. > And I really don't like this: Microsoft announced GDI+ as the new generation > of drawing framework for windows, and just some years later it is already > old and not supported. > This seems to me a real waste of time, experience and money. >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |