Why Avalon cost so much memory?
Lei Jiang
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??
Frank Hileman
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" <co...@263.net> wrote in message
news:O4%23g%23342E...@TK2MSFTNGP12.phx.gbl...
Rob Relyea [msft]
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.
Thanks,
Rob Relyea
Avalon Team
http://longhornblogs.com/rrelyea
"Frank Hileman" <fran...@no.spamming.prodigesoftware.com> wrote in message
news:eBgQwB72...@TK2MSFTNGP10.phx.gbl...
Lei Jiang
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" <fran...@no.spamming.prodigesoftware.com> 写入消息
news:eBgQwB72...@TK2MSFTNGP10.phx.gbl...
Lei Jiang
"Rob Relyea [msft]" <rre...@online.microsoft.com> 写入消息
news:#7kwe4H3...@TK2MSFTNGP15.phx.gbl...
Feng Yuan [MSFT]
application.
For intensive graphics application, you should consider operate at Visual
level, instead of UIElement level. Check for DrawingVisual, OnDemandVisual,
DrawingContext, etc.
--
Feng Yuan (www.fengyuan.com)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Lei Jiang" <co...@263.net> wrote in message
news:O4%23g%23342E...@TK2MSFTNGP12.phx.gbl...
Lei Jiang
"Feng Yuan [MSFT]" <fy...@online.microsoft.com> 写入消息
news:#hrl9nP3...@TK2MSFTNGP15.phx.gbl...
Frank Hileman
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
"Lei Jiang" <co...@263.net> wrote in message
news:ur$uM%23M3EH...@tk2msftngp13.phx.gbl...
Drew Marsh
> 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").
HTH,
Drew
[1] See the bottom of this page: http://winfx.msdn.microsoft.com/?//winfx.msdn.microsoft.com/winfx/ref/ns/system.windows/c/uielement/uielement.aspx
Lei Jiang
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?
"Drew Marsh" <dru...@hotmail.no.spamming.com> ????
news:107437632381...@msnews.microsoft.com...
Lei Jiang
"Frank Hileman" <fran...@no.spamming.prodigesoftware.com> 写入消息
news:OjjaHWT3...@TK2MSFTNGP09.phx.gbl...
Drew Marsh
> 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).
Just my 2¢,
Drew
[1] http://winfx.msdn.microsoft.com/?//winfx.msdn.microsoft.com/winfx/ref/ns/system.windows.media/c/drawingvisual/drawingvisual.aspx
[2] http://winfx.msdn.microsoft.com/?//winfx.msdn.microsoft.com/winfx/ref/ns/system.windows.media/c/drawingcontext/drawingcontext.aspx
[3] http://winfx.msdn.microsoft.com/?//winfx.msdn.microsoft.com/winfx/ref/ns/system.windows.media/c/drawingvisual/m/renderopen.aspx
Edward Wohlman
Layout, Input, Focus, and Eventing
LIFE begins at UIElement
;-)
I've been thinking about and playing with this stuff for days and I
still can't get enough of it.
Great work Avalon Team.
Lei Jiang
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!
"Drew Marsh" <dru...@hotmail.no.spamming.com> ????
news:108705632381...@msnews.microsoft.com...
Lei Jiang
and the relations between them.
"Rob Relyea [msft]" <rre...@online.microsoft.com> 写入消息
news:#7kwe4H3...@TK2MSFTNGP15.phx.gbl...
Yin XIE - Microsoft Avalon Team
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.
Happy New Year!
Yin
Frank Hileman
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
"Yin XIE - Microsoft Avalon Team" <yin...@gmail.com> wrote in message
news:1105379149.3...@f14g2000cwb.googlegroups.com...
Lei Jiang
Hi Yin,
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?
Lei
"Yin XIE - Microsoft Avalon Team" <yin...@gmail.com> ????
news:1105379149.3...@f14g2000cwb.googlegroups.com...
Lei Jiang
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+?
Thanks!
"Yin XIE - Microsoft Avalon Team" <yin...@gmail.com> wrote in message
news:1105379149.3...@f14g2000cwb.googlegroups.com...
>
Frank Hileman
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
"Lei Jiang" <co...@263.net> wrote in message
news:uFyoNV1A...@TK2MSFTNGP11.phx.gbl...
Drew Marsh
> (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.
Cheers,
Drew
[1] http://blogs.officezealot.com/rod/archive/2005/01/18/3885.aspx
________________
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. :)
Frank Hileman
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
news:198407632423...@msnews.microsoft.com...
Drew Marsh
> 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.
Thanks,
Drew