I did a simple test just now : add 10000 ellipses and 10000 line segments to a canvas. This simple program cost about 90MB memory!( and costs 7s)
308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
Another problem is of hardware accecelating. I checked my DirectX settings (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled on my computer(Win2003). After I turned the hardware accecelating on and enable the DirectDraw/Direct3D. The same test cost more time! For the first test, it cost 12s, the second cost 70s. Is the software rendering faster than hardware accecelating??
To add a little perspective, you might look at the performance of a similar system. In VG.net (a vector graphics system based on GDI+) there is a sample called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, creation time for rectangles:
10K: 0.01 seconds 100K: 0.10 seconds
Peak memory consumption during 100% animation of every rectangle, by constantly changing their location:
10K: 16MB 100K: 23MB
Virtual memory usage is smaller, and memory usage is lower with no animation. Considering that the application consumed 9MB before any objects were created, simply displaying the test control panel, I think that is fairly efficient.
Avalon is not even in beta yet. After all the performance testing and tuning it will probably work a bit better. But there are some fundamental low level data structures and techniques in Avalon that look unscalable to me, so I don't think the integrated retained mode system will be useful for CAD, GIS, and certain types of SCADA vector graphics.
Regards, Frank Hileman
check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor
>I did a simple test just now : add 10000 ellipses and 10000 line segments >to > a canvas. This simple program cost about 90MB memory!( and costs 7s)
> 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
> Another problem is of hardware accecelating. I checked my DirectX settings > (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled > on > my computer(Win2003). After I turned the hardware accecelating on and > enable > the DirectDraw/Direct3D. The same test cost more time! For the first test, > it cost 12s, the second cost 70s. Is the software rendering faster than > hardware accecelating??
All- Our perf team is working with Lei to get his code and to work through this issue. There are several ways to draw in Avalon, we need to give good descriptions of those different techniques and give guidance as to when to use which one.
We hope to have the beginnings of that in the next week or two.
> To add a little perspective, you might look at the performance of a > similar system. In VG.net (a vector graphics system based on GDI+) there > is a sample called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, > creation time for rectangles:
> 10K: 0.01 seconds > 100K: 0.10 seconds
> Peak memory consumption during 100% animation of every rectangle, by > constantly changing their location:
> 10K: 16MB > 100K: 23MB
> Virtual memory usage is smaller, and memory usage is lower with no > animation. Considering that the application consumed 9MB before any > objects were created, simply displaying the test control panel, I think > that is fairly efficient.
> Avalon is not even in beta yet. After all the performance testing and > tuning it will probably work a bit better. But there are some fundamental > low level data structures and techniques in Avalon that look unscalable to > me, so I don't think the integrated retained mode system will be useful > for CAD, GIS, and certain types of SCADA vector graphics.
> Regards, > Frank Hileman
> check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor
> "Lei Jiang" <c...@263.net> wrote in message > news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... >>I did a simple test just now : add 10000 ellipses and 10000 line segments >>to >> a canvas. This simple program cost about 90MB memory!( and costs 7s)
>> 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
>> Another problem is of hardware accecelating. I checked my DirectX >> settings >> (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled >> on >> my computer(Win2003). After I turned the hardware accecelating on and >> enable >> the DirectDraw/Direct3D. The same test cost more time! For the first >> test, >> it cost 12s, the second cost 70s. Is the software rendering faster than >> hardware accecelating??
> To add a little perspective, you might look at the performance of a similar > system. In VG.net (a vector graphics system based on GDI+) there is a sample > called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, creation time > for rectangles:
> 10K: 0.01 seconds > 100K: 0.10 seconds
> Peak memory consumption during 100% animation of every rectangle, by > constantly changing their location:
> 10K: 16MB > 100K: 23MB
> Virtual memory usage is smaller, and memory usage is lower with no > animation. Considering that the application consumed 9MB before any objects > were created, simply displaying the test control panel, I think that is > fairly efficient.
> Avalon is not even in beta yet. After all the performance testing and tuning > it will probably work a bit better. But there are some fundamental low level > data structures and techniques in Avalon that look unscalable to me, so I > don't think the integrated retained mode system will be useful for CAD, GIS, > and certain types of SCADA vector graphics.
> Regards, > Frank Hileman
> check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor
> "Lei Jiang" <c...@263.net> wrote in message > news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... > >I did a simple test just now : add 10000 ellipses and 10000 line segments > >to > > a canvas. This simple program cost about 90MB memory!( and costs 7s)
> > 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
> > Another problem is of hardware accecelating. I checked my DirectX settings > > (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled > > on > > my computer(Win2003). After I turned the hardware accecelating on and > > enable > > the DirectDraw/Direct3D. The same test cost more time! For the first test, > > it cost 12s, the second cost 70s. Is the software rendering faster than > > hardware accecelating??
> All- > Our perf team is working with Lei to get his code and to work through this > issue. > There are several ways to draw in Avalon, we need to give good descriptions > of those different techniques and give guidance as to when to use which one.
> We hope to have the beginnings of that in the next week or two.
> "Frank Hileman" <frank...@no.spamming.prodigesoftware.com> wrote in message > news:eBgQwB72EHA.1292@TK2MSFTNGP10.phx.gbl... > > To add a little perspective, you might look at the performance of a > > similar system. In VG.net (a vector graphics system based on GDI+) there > > is a sample called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, > > creation time for rectangles:
> > 10K: 0.01 seconds > > 100K: 0.10 seconds
> > Peak memory consumption during 100% animation of every rectangle, by > > constantly changing their location:
> > 10K: 16MB > > 100K: 23MB
> > Virtual memory usage is smaller, and memory usage is lower with no > > animation. Considering that the application consumed 9MB before any > > objects were created, simply displaying the test control panel, I think > > that is fairly efficient.
> > Avalon is not even in beta yet. After all the performance testing and > > tuning it will probably work a bit better. But there are some fundamental > > low level data structures and techniques in Avalon that look unscalable to > > me, so I don't think the integrated retained mode system will be useful > > for CAD, GIS, and certain types of SCADA vector graphics.
> > Regards, > > Frank Hileman
> > check out VG.net: http://www.vgdotnet.com > > Animated vector graphics system > > Integrated Visual Studio .NET graphics editor
> > "Lei Jiang" <c...@263.net> wrote in message > > news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... > >>I did a simple test just now : add 10000 ellipses and 10000 line segments > >>to > >> a canvas. This simple program cost about 90MB memory!( and costs 7s)
> >> 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
> >> Another problem is of hardware accecelating. I checked my DirectX > >> settings > >> (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled > >> on > >> my computer(Win2003). After I turned the hardware accecelating on and > >> enable > >> the DirectDraw/Direct3D. The same test cost more time! For the first > >> test, > >> it cost 12s, the second cost 70s. Is the software rendering faster than > >> hardware accecelating??
Canvas, which is based on UIElement, is not designed intensive graphics application.
For intensive graphics application, you should consider operate at Visual level, instead of UIElement level. Check for DrawingVisual, OnDemandVisual, DrawingContext, etc.
> Canvas, which is based on UIElement, is not designed intensive graphics > application.
> For intensive graphics application, you should consider operate at Visual > level, instead of UIElement level. Check for DrawingVisual, OnDemandVisual, > DrawingContext, etc.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Lei Jiang" <c...@263.net> wrote in message > news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... > >I did a simple test just now : add 10000 ellipses and 10000 line segments > >to > > a canvas. This simple program cost about 90MB memory!( and costs 7s)
> > 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
It can only do better if it does not consume massive amounts of memory per element, and uses optimized algorithms. The rendering engine is only one factor.
Regards, Frank Hileman
check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor
> VG.net is great. But I beleive Avalon will do better, since it fully > explore > the hardware capacity while GDI/GDi+ does not.
> "Frank Hileman" <frank...@no.spamming.prodigesoftware.com> дÈëÏûÏ¢ > news:eBgQwB72EHA.1292@TK2MSFTNGP10.phx.gbl... >> To add a little perspective, you might look at the performance of a > similar >> system. In VG.net (a vector graphics system based on GDI+) there is a > sample >> called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, creation time >> for rectangles:
>> 10K: 0.01 seconds >> 100K: 0.10 seconds
>> Peak memory consumption during 100% animation of every rectangle, by >> constantly changing their location:
>> 10K: 16MB >> 100K: 23MB
>> Virtual memory usage is smaller, and memory usage is lower with no >> animation. Considering that the application consumed 9MB before any > objects >> were created, simply displaying the test control panel, I think that is >> fairly efficient.
>> Avalon is not even in beta yet. After all the performance testing and > tuning >> it will probably work a bit better. But there are some fundamental low > level >> data structures and techniques in Avalon that look unscalable to me, so I >> don't think the integrated retained mode system will be useful for CAD, > GIS, >> and certain types of SCADA vector graphics.
>> Regards, >> Frank Hileman
>> check out VG.net: http://www.vgdotnet.com >> Animated vector graphics system >> Integrated Visual Studio .NET graphics editor
>> "Lei Jiang" <c...@263.net> wrote in message >> news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... >> >I did a simple test just now : add 10000 ellipses and 10000 line >> >segments >> >to >> > a canvas. This simple program cost about 90MB memory!( and costs 7s)
>> > 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
>> > Another problem is of hardware accecelating. I checked my DirectX > settings >> > (using dxdiag.exe) and found that the DirectDraw and Direct3D is > disabled >> > on >> > my computer(Win2003). After I turned the hardware accecelating on and >> > enable >> > the DirectDraw/Direct3D. The same test cost more time! For the first > test, >> > it cost 12s, the second cost 70s. Is the software rendering faster than >> > hardware accecelating??
Lei Jiang wrote: > Do Visual level objects support animation, hittest, etc?
All LIFE[1] support is added at UIElement. That's why visuals are so much cheaper. You should be able to animate a Visual's properties, since Visual derives from DependencyObject, but you'll have to render the Visual yourself. Also, Visual supports hit testing via HitTestCore and HitTestBounds, but you don't have any nice events provided for you like you do on UIElement (one of the major reasons it's "lighter").
Thanks! I understand that Visual is much "lighter" than UIElement. Since I have a lot of objects to be rendered to window, it seems I have to render the Visual by myself... :-(
Could the UIElement be more lighter in Avalon? Or is there a mechanism that support large amount of UIElement effeciently?
> > Do Visual level objects support animation, hittest, etc?
> All LIFE[1] support is added at UIElement. That's why visuals are so much > cheaper. You should be able to animate a Visual's properties, since Visual > derives from DependencyObject, but you'll have to render the Visual yourself. > Also, Visual supports hit testing via HitTestCore and HitTestBounds, but > you don't have any nice events provided for you like you do on UIElement > (one of the major reasons it's "lighter").
> It can only do better if it does not consume massive amounts of memory per > element, and uses optimized algorithms. The rendering engine is only one > factor.
> Regards, > Frank Hileman
> check out VG.net: http://www.vgdotnet.com > Animated vector graphics system > Integrated Visual Studio .NET graphics editor
> > VG.net is great. But I beleive Avalon will do better, since it fully > > explore > > the hardware capacity while GDI/GDi+ does not.
> > "Frank Hileman" <frank...@no.spamming.prodigesoftware.com> дÈëÏûÏ¢ > > news:eBgQwB72EHA.1292@TK2MSFTNGP10.phx.gbl... > >> To add a little perspective, you might look at the performance of a > > similar > >> system. In VG.net (a vector graphics system based on GDI+) there is a > > sample > >> called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, creation time > >> for rectangles:
> >> 10K: 0.01 seconds > >> 100K: 0.10 seconds
> >> Peak memory consumption during 100% animation of every rectangle, by > >> constantly changing their location:
> >> 10K: 16MB > >> 100K: 23MB
> >> Virtual memory usage is smaller, and memory usage is lower with no > >> animation. Considering that the application consumed 9MB before any > > objects > >> were created, simply displaying the test control panel, I think that is > >> fairly efficient.
> >> Avalon is not even in beta yet. After all the performance testing and > > tuning > >> it will probably work a bit better. But there are some fundamental low > > level > >> data structures and techniques in Avalon that look unscalable to me, so I > >> don't think the integrated retained mode system will be useful for CAD, > > GIS, > >> and certain types of SCADA vector graphics.
> >> Regards, > >> Frank Hileman
> >> check out VG.net: http://www.vgdotnet.com > >> Animated vector graphics system > >> Integrated Visual Studio .NET graphics editor
> >> "Lei Jiang" <c...@263.net> wrote in message > >> news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... > >> >I did a simple test just now : add 10000 ellipses and 10000 line > >> >segments > >> >to > >> > a canvas. This simple program cost about 90MB memory!( and costs 7s)
> >> > 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
> >> > Another problem is of hardware accecelating. I checked my DirectX > > settings > >> > (using dxdiag.exe) and found that the DirectDraw and Direct3D is > > disabled > >> > on > >> > my computer(Win2003). After I turned the hardware accecelating on and > >> > enable > >> > the DirectDraw/Direct3D. The same test cost more time! For the first > > test, > >> > it cost 12s, the second cost 70s. Is the software rendering faster than > >> > hardware accecelating??
> Thanks! I understand that Visual is much "lighter" than UIElement. > Since I have a lot of objects to be rendered to window, it seems I > have to render the Visual by myself... :-(
Also, make sure you check out DrawingVisual[1]. You can simply open yourself a DrawingContext[2] with RenderOpen[3] and go to town painting as much as you want onto the same surface area. DrawingContext is basically the Avalon equivalent of System.Drawing.Graphics.
> Could the UIElement be more lighter in Avalon? Or is there a mechanism > that support large amount of UIElement effeciently?
I can't answer that one obviously, but I believe from a design standpoint Microsoft has made the right choices in terms of the way they designed the class Avalon class heirarchy in terms of making a distinction between a simple graphics element (Visual) and an rich interactive element (UIElement).
>> Do Visual level objects support animation, hittest, etc?
> All LIFE[1] support is added at UIElement. That's why visuals are so > much cheaper. You should be able to animate a Visual's properties, > since Visual derives from DependencyObject, but you'll have to render > the Visual yourself. Also, Visual supports hit testing via HitTestCore > and HitTestBounds, but you don't have any nice events provided for you > like you do on UIElement (one of the major reasons it's "lighter").
Yes, this design decision is right. The simpel graphics element should be separated from interactive UIElement. I wish the UIElement implementation be lighter, so I can save a lot of work :-) The Avalon team is doing a great work!
> > Thanks! I understand that Visual is much "lighter" than UIElement. > > Since I have a lot of objects to be rendered to window, it seems I > > have to render the Visual by myself... :-(
> Also, make sure you check out DrawingVisual[1]. You can simply open yourself > a DrawingContext[2] with RenderOpen[3] and go to town painting as much as > you want onto the same surface area. DrawingContext is basically the Avalon > equivalent of System.Drawing.Graphics.
> > Could the UIElement be more lighter in Avalon? Or is there a mechanism > > that support large amount of UIElement effeciently?
> I can't answer that one obviously, but I believe from a design standpoint > Microsoft has made the right choices in terms of the way they designed the > class Avalon class heirarchy in terms of making a distinction between a simple > graphics element (Visual) and an rich interactive element (UIElement).
> All- > Our perf team is working with Lei to get his code and to work through this > issue. > There are several ways to draw in Avalon, we need to give good descriptions > of those different techniques and give guidance as to when to use which one.
> We hope to have the beginnings of that in the next week or two.
> "Frank Hileman" <frank...@no.spamming.prodigesoftware.com> wrote in message > news:eBgQwB72EHA.1292@TK2MSFTNGP10.phx.gbl... > > To add a little perspective, you might look at the performance of a > > similar system. In VG.net (a vector graphics system based on GDI+) there > > is a sample called Scalability. Using version 2.3 (beta), a 1.7 GHz P4, > > creation time for rectangles:
> > 10K: 0.01 seconds > > 100K: 0.10 seconds
> > Peak memory consumption during 100% animation of every rectangle, by > > constantly changing their location:
> > 10K: 16MB > > 100K: 23MB
> > Virtual memory usage is smaller, and memory usage is lower with no > > animation. Considering that the application consumed 9MB before any > > objects were created, simply displaying the test control panel, I think > > that is fairly efficient.
> > Avalon is not even in beta yet. After all the performance testing and > > tuning it will probably work a bit better. But there are some fundamental > > low level data structures and techniques in Avalon that look unscalable to > > me, so I don't think the integrated retained mode system will be useful > > for CAD, GIS, and certain types of SCADA vector graphics.
> > Regards, > > Frank Hileman
> > check out VG.net: http://www.vgdotnet.com > > Animated vector graphics system > > Integrated Visual Studio .NET graphics editor
> > "Lei Jiang" <c...@263.net> wrote in message > > news:O4%23g%23342EHA.936@TK2MSFTNGP12.phx.gbl... > >>I did a simple test just now : add 10000 ellipses and 10000 line segments > >>to > >> a canvas. This simple program cost about 90MB memory!( and costs 7s)
> >> 308MB when 50000 ellipse and 50000 line segments added. (costs 43s)
> >> Another problem is of hardware accecelating. I checked my DirectX > >> settings > >> (using dxdiag.exe) and found that the DirectDraw and Direct3D is disabled > >> on > >> my computer(Win2003). After I turned the hardware accecelating on and > >> enable > >> the DirectDraw/Direct3D. The same test cost more time! For the first > >> test, > >> it cost 12s, the second cost 70s. Is the software rendering faster than > >> hardware accecelating??
Thank you for evaluating Avalon and looking into performance issues. We have done an investigation on the working set and execution speed issues. We could reproduce both issues with the code you provided to us.
In your code, you use Line Shapes instead of drawing the lines directly using a DrawingContext as shown in the following code. public class MyCanvas : Canvas { protected override void OnRender(DrawingContext ctx) { Pen pen = new Pen(Brushes.Red, DrawLines.W); for (int i = 0; i < DrawLines.N; i++) { ctx.DrawLine( pen, new Point (DrawLines.X1, DrawLines.Y1), new Point (DrawLines.X2, DrawLines.Y2) );
} // end of for loop } // end of OnRender } // end of class MyCanvas
Line shapes can not scale as well as calling DrawLines which is what you would do using GDI+. Line shapes provide much richer functionalities than you would ever need in your scenarios, such as Styling, element composition, etc. I rewrote your sample using OnRender override shown as above, the working set is about 20 Mbytes for 10000 lines and 10000 ellipses.
Regarding the speed issue, we discovered and fixed a bug which makes the 1px line slower than wider lines. With hardware acceleration, Avalon drawing routines scales much better than GDI+ even though there is some initial higher fixed cost. Here is some data on the scalability of drawing lines:
Cost per line for 1 pixel wide lines from (0,0) to (800, 600) in microseconds #of lines Avalon GDI+ AA GDI+ default 1 N/A 7272 3575 10 4398.7 3821.6 574.3 100 505.53 3099.84 197.73 1000 55.623 3067.83 177.248 10000 29.3183 3083.0717 176.9431 100000 88.89802 3071.06664 178.76963
I would like also to point out that Avalon is doing 8X8 anti-aliasing by default. Thus the visual quality with Avalon is much higher than any GDI+ mode.
If you have to use the DrawingContext and write your own retained mode system, why use Avalon at all then? Does it have much more functionality over DirectX when used this way? It seems the DrawingContext does not support many of the drawing operations in GDI+, such as path gradients. Are there plans to support all the GDI+ drawing operations and features?
Regards, Frank Hileman
check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor
> Thank you for evaluating Avalon and looking into performance issues. We > have done an investigation on the working set and execution speed > issues. We could reproduce both issues with the code you provided to > us.
> In your code, you use Line Shapes instead of drawing the lines directly > using a DrawingContext as shown in the following code. > public class MyCanvas : Canvas > { > protected override void OnRender(DrawingContext ctx) > { > Pen pen = new Pen(Brushes.Red, DrawLines.W); > for (int i = 0; i < DrawLines.N; i++) > { > ctx.DrawLine( > pen, > new Point (DrawLines.X1, DrawLines.Y1), > new Point (DrawLines.X2, DrawLines.Y2) > ); > } // end of for loop > } // end of OnRender > } // end of class MyCanvas
> Line shapes can not scale as well as calling DrawLines which is what > you would do using GDI+. Line shapes provide much richer > functionalities than you would ever need in your scenarios, such as > Styling, element composition, etc. I rewrote your sample using OnRender > override shown as above, the working set is about 20 Mbytes for 10000 > lines and 10000 ellipses.
> Regarding the speed issue, we discovered and fixed a bug which makes > the 1px line slower than wider lines. With hardware acceleration, > Avalon drawing routines scales much better than GDI+ even though there > is some initial higher fixed cost. Here is some data on the scalability > of drawing lines:
> Cost per line for 1 pixel wide lines from (0,0) to (800, 600) in > microseconds > #of lines Avalon GDI+ AA GDI+ default > 1 N/A 7272 3575 > 10 4398.7 3821.6 574.3 > 100 505.53 3099.84 197.73 > 1000 55.623 3067.83 177.248 > 10000 29.3183 3083.0717 176.9431 > 100000 88.89802 3071.06664 178.76963
> I would like also to point out that Avalon is doing 8X8 anti-aliasing > by default. Thus the visual quality with Avalon is much higher than any > GDI+ mode.
Thank you for your help. However, I have to use Shapes instead of DrawingContext. Yes, using DrawingContext would be much faster than using Shapes, but I have to use such features as Styling, animation, etc in my system. The code I provided to you is just a test in which I want to know the speed of shape system.
Could the performance of Shape system be improved?
> Thank you for evaluating Avalon and looking into performance issues. We > have done an investigation on the working set and execution speed > issues. We could reproduce both issues with the code you provided to > us.
> In your code, you use Line Shapes instead of drawing the lines directly > using a DrawingContext as shown in the following code. > public class MyCanvas : Canvas > { > protected override void OnRender(DrawingContext ctx) > { > Pen pen = new Pen(Brushes.Red, DrawLines.W); > for (int i = 0; i < DrawLines.N; i++) > { > ctx.DrawLine( > pen, > new Point (DrawLines.X1, DrawLines.Y1), > new Point (DrawLines.X2, DrawLines.Y2) > ); > } // end of for loop > } // end of OnRender > } // end of class MyCanvas
> Line shapes can not scale as well as calling DrawLines which is what > you would do using GDI+. Line shapes provide much richer > functionalities than you would ever need in your scenarios, such as > Styling, element composition, etc. I rewrote your sample using OnRender > override shown as above, the working set is about 20 Mbytes for 10000 > lines and 10000 ellipses.
> Regarding the speed issue, we discovered and fixed a bug which makes > the 1px line slower than wider lines. With hardware acceleration, > Avalon drawing routines scales much better than GDI+ even though there > is some initial higher fixed cost. Here is some data on the scalability > of drawing lines:
> Cost per line for 1 pixel wide lines from (0,0) to (800, 600) in > microseconds > #of lines Avalon GDI+ AA GDI+ default > 1 N/A 7272 3575 > 10 4398.7 3821.6 574.3 > 100 505.53 3099.84 197.73 > 1000 55.623 3067.83 177.248 > 10000 29.3183 3083.0717 176.9431 > 100000 88.89802 3071.06664 178.76963
> I would like also to point out that Avalon is doing 8X8 anti-aliasing > by default. Thus the visual quality with Avalon is much higher than any > GDI+ mode.
Since you mentioned that Avalon is doing 8X8 anti-aliasing "by default", could I configure the anti-aliasing settings to achieve a better quality? Or lower that to achieve a better speed? What's the current settings for GDI/GDI+?
> Cost per line for 1 pixel wide lines from (0,0) to (800, 600) in > microseconds > #of lines Avalon GDI+ AA GDI+ default > 1 N/A 7272 3575 > 10 4398.7 3821.6 574.3 > 100 505.53 3099.84 197.73 > 1000 55.623 3067.83 177.248 > 10000 29.3183 3083.0717 176.9431 > 100000 88.89802 3071.06664 178.76963
> I would like also to point out that Avalon is doing 8X8 anti-aliasing > by default. Thus the visual quality with Avalon is much higher than any > GDI+ mode.
The problem is, if you have 10K objects drawn with Avalon (DrawingContext), and 10 of them change, in an optimized retained mode system (like VG.net) only those 10, plus overlapping areas, need to be redrawn. In the non-editable DrawingContext code, all 10K need to be redrawn. So any performance gain over GDI+ is squandered in most cases, especially in your type of SCADA application.
We really need an immediate-mode replacement for GDI+, not a non-editable retained mode system, that does not support efficient style information references. With an immediate-mode replacement truly scalable systems may be built on top.
I imagine you will need a separate Canvas per object and then you will run into the same kind of scalability problems Avalon has with Shapes.
Regards, Frank Hileman
check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor
> Since you mentioned that Avalon is doing 8X8 anti-aliasing "by default", > could I configure the anti-aliasing settings to achieve a better quality? > Or lower that to achieve a better speed? What's the current settings for > GDI/GDI+?
>> Cost per line for 1 pixel wide lines from (0,0) to (800, 600) in >> microseconds >> #of lines Avalon GDI+ AA GDI+ default >> 1 N/A 7272 3575 >> 10 4398.7 3821.6 574.3 >> 100 505.53 3099.84 197.73 >> 1000 55.623 3067.83 177.248 >> 10000 29.3183 3083.0717 176.9431 >> 100000 88.89802 3071.06664 178.76963
>> I would like also to point out that Avalon is doing 8X8 anti-aliasing >> by default. Thus the visual quality with Avalon is much higher than any >> GDI+ mode.
> The problem is, if you have 10K objects drawn with Avalon > (DrawingContext), and 10 of them change, in an optimized retained mode > system (like VG.net) only those 10, plus overlapping areas, need to be > redrawn. In the non-editable DrawingContext code, all 10K need to be > redrawn. So any performance gain over GDI+ is squandered in most > cases, especially in your type of SCADA application.
> We really need an immediate-mode replacement for GDI+, not a > non-editable retained mode system, that does not support efficient > style information references. With an immediate-mode replacement truly > scalable systems may be built on top.
> I imagine you will need a separate Canvas per object and then you will > run into the same kind of scalability problems Avalon has with Shapes.
Frank,
I'm guessing you didn't see my follow up comment here[1]. I'll paste it below for newsgroup discussion as well.
Well, I'm no authority on this subject so forgive me if I'm totally off base here, but I still believe what you want is possible.
If you look at the Longhorn SDK you'll see an interface called IRetainedRender[1] and you'll find a class called RetainedVisual[2] with a property called RenderBounds[3]. When IRetainedRender is implemented by a class, the RetainedVisual's RenderBounds will be set to indicate what area to redraw.
Now, in the CTP drop, RetainedVisual seems to have been renamed OnDemandVisual[3]. OnDemandVisual has a RenderBounds property. What's missing though is the marker interface IRetainedRender. So, I'm just not sure how to indicate that you want to only be notified for partial redraws.
So, is this what you're looking for? You would maintain your 100k object graph in whatever efficient internal form you like and only redraw the region that has been invalidated based on whatever data in the graph represents that area.
Anyway, like I said, if I'm totally off base here I apologize. Maybe a small example of how you would achieve this in .NET with System.Drawing.Graphics today would help get the point across. At this point if I'm not getting it I'd actually love to learn more about it. :)
According to the "About Avalon Memory Cost" thread in this group, the "retained" part of a Visual is not a bitmap but a stream of low-level rendering commands, which is not editable (see Tim Cahill reply). So this is not an immediate-mode replacement for GDI+. If it is to be a retained mode replacement for GDI+, it would have to be efficiently editable, and it would need to have an efficient storage for traditional styling information (stroke width, fill, etc), so that common styling information could be used by reference without duplication within the command stream. This is what I call a context-dependent rendering system.
If Visual were a bitmap buffer, a single bounds is not enough to optimize screen updates. If two small objects, one on the upper left, and one on the lower right, are animated, the union is the entire screen. Part of the optimization in such a case is managing multiple invalid areas simultaneously and batching the display. It is important both for pruning (culling) and clipping.
Because we are talking about a non-bitmap based buffer, I believe that bounds is irrelevant. I think it defines the area to render in its totality and not a portion, but it is not documented.
Regards, Frank Hileman
check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor
"Drew Marsh" <dru...@hotmail.no.spamming.com> wrote in message
>> The problem is, if you have 10K objects drawn with Avalon >> (DrawingContext), and 10 of them change, in an optimized retained mode >> system (like VG.net) only those 10, plus overlapping areas, need to be >> redrawn. In the non-editable DrawingContext code, all 10K need to be >> redrawn. So any performance gain over GDI+ is squandered in most >> cases, especially in your type of SCADA application.
>> We really need an immediate-mode replacement for GDI+, not a >> non-editable retained mode system, that does not support efficient >> style information references. With an immediate-mode replacement truly >> scalable systems may be built on top.
>> I imagine you will need a separate Canvas per object and then you will >> run into the same kind of scalability problems Avalon has with Shapes.
> Frank, > I'm guessing you didn't see my follow up comment here[1]. I'll paste it > below for newsgroup discussion as well.
> Frank, > Well, I'm no authority on this subject so forgive me if I'm totally off > base here, but I still believe what you want is possible. > If you look at the Longhorn SDK you'll see an interface called > IRetainedRender[1] and you'll find a class called RetainedVisual[2] with a > property called RenderBounds[3]. When IRetainedRender is implemented by a > class, the RetainedVisual's RenderBounds will be set to indicate what area > to redraw. > Now, in the CTP drop, RetainedVisual seems to have been renamed > OnDemandVisual[3]. OnDemandVisual has a RenderBounds property. What's > missing though is the marker interface IRetainedRender. So, I'm just not > sure how to indicate that you want to only be notified for partial > redraws. > So, is this what you're looking for? You would maintain your 100k object > graph in whatever efficient internal form you like and only redraw the > region that has been invalidated based on whatever data in the graph > represents that area. > Anyway, like I said, if I'm totally off base here I apologize. Maybe a > small example of how you would achieve this in .NET with > System.Drawing.Graphics today would help get the point across. At this > point if I'm not getting it I'd actually love to learn more about it. :) > [1] > http://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhs... > [2] > http://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhs... > [3] > http://longhorn.msdn.microsoft.com/?//longhorn.msdn.microsoft.com/lhs... > [4] > http://winfx.msdn.microsoft.com/?//winfx.msdn.microsoft.com/winfx/ref...
> According to the "About Avalon Memory Cost" thread in this group, the > "retained" part of a Visual is not a bitmap but a stream of low-level > rendering commands, which is not editable (see Tim Cahill reply).
Thanks, now I understand what you mean by rendering commands. I didn't realize that this was the way the rendering architecture worked, but seeing as how everything has to undergo various matrix transforms and still provide a sharp image, it makes perfect sense it can't be bitmap based.
> So > this is not an immediate-mode replacement for GDI+. If it is to be a > retained mode replacement for GDI+, it would have to be efficiently > editable, and it would need to have an efficient storage for > traditional styling information (stroke width, fill, etc), so that > common styling information could be used by reference without > duplication within the command stream. This is what I call a > context-dependent rendering system.
I think I understand now.
> If Visual were a bitmap buffer, a single bounds is not enough to > optimize screen updates. If two small objects, one on the upper left, > and one on the lower right, are animated, the union is the entire > screen. Part of the optimization in such a case is managing multiple > invalid areas simultaneously and batching the display. It is important > both for pruning (culling) and clipping.
Sure, that makes sense, but I thought RenderBounds was intended to be used when you're being *told* what area to repaint (i.e. someone moved something over you and then back off). If you need to repaint yourself because two of your objects updated, I would imagine that you could render into any portion of the area you wanted using whatever logic you wanted. For example, how would you do this today as a System.Windows.Forms.Control? Wouldn't you just Invalidate yourself and then use whatever internal logic you needed inside of OnPaint to make sure that you only paint the areas that have changed? Just curious... I honestly am no expert in this area and am just trying to learn some more about it. Any detail you can provide on how you solve this problem using pure GDI+ today would be appreciated. ;)
> Because we are talking about a non-bitmap based buffer, I believe that > bounds is irrelevant. I think it defines the area to render in its > totality and not a portion, but it is not documented.
Gotcha. Yeah we could definitely use some more official details on this subject. An article like "DrawingContext De-Mystified" would be awesome. It's fascinating to me and seems like a limitation for programs of the type you mention if, in fact, every command stream is recreated for every Visual.
|
