From a comment:
"OT: terribly bad form to pull the comments off-topic,
but here goes.
I just watched the PRS315 PDC video hoping to get the answer to the blog question
listed in the slideshow:
"How do we get large numbers of visuals to perform? If we have 100,000 eleemnts to
display in a system how do we make it perform? With an immediate draw API I can omit
drawing that is out of view or too small to be visible. Where is there some conditionality
in the visual hierarchy?"
But the discussion never got round to that question. :'(
Do you know anyone at Microsoft who could talk/write/blog knowledgeably on the topic
and if so, are you prepared to prod them to do so? Alternatively, maybe its already
been answered somewhere.
Yours,
Confused Programmer (hoping he doesnt have to re-implement the wheel at the DirectX
level, given how suitable the WPF wheel looks, at least on the surface)."
There are several options on how to achieve this, the two main things you need is
to have logic to omit elements that aren't visible (which you mention) and carefully
choose what needs interactivity and what doesn't. There are three primary ways to
create visuals in Avalon - UIElements, Drawings, and DrawingContext.
UIElements are the shapes, buttons, and other controls you know and love. They support
input, eventing, layout, etc. Typically a single UIElement will create more than one
visual, and the internals of Avalon has to track bounding boxes, input state, and
lots of other goo. You can create a scene with tens of thousands of elements that
performs adaquately, but that is really pushing the upper limits based on memory and
GPU bandwidth. We are working hard to optimize this, but I would suggest that if you
have more than 5K elements, you'll want to start doing something different.
Drawings are a lightweight object model on top of the underlying render data that
the rendering engine uses. Think of this as object oriented GDI. Drawings don't have
input, etc, they tend to be a lot more lightweight. Drawings can scale to the size
of tens of thousands pretty easily, however you are still allocating managed objects
for all of these.
DrawingContext is the closest to an immediate mode API that Avalon has. DrawingContext
directly manipulates the render data that the engine uses. This avoids the managed
object overhead, and you are now just working on a binary stream of data used to render.
This can scale quite well to very large numbers.
All of that said, Avalon is a retained mode vector based graphics system. So, creating
a very complex scene can cause the system to bog down, especially if you do anything
to force software rendering (BitmapEffects like a drop shadow, or complex opacity
effects with the OpacityMask, etc).
You as the data provider is in the best position to optimize the visuals that you
create. Just as a stupid example, you wouldn't implement Virtual Earth by rendering
all the visuals at all depth for the world and then just panning around. Nothing would
scale to that level.
I'm not sure your exact scenario, but depending on what you are doing one of the three
APIs above should hopefully give you the features, performance, and scalability that
you need. The last bit is to write some type of host that performs the render. When
I wrote a Virtual Earth host in Avalon, I ended up writing a custom panel that overrode
OnRender. I needed a panel because I wanted to support layout of pushpins, but then
only the layout new where the map tiles should be placed. It worked pretty well, but
of course it violated some of the purist views of what a panel shoudl do... but code
wins :)
Good Luck!