Is the Canvas model scalable?

Article
09/15/2004

Miguel has a list of concerns with the Avalon architecture. I'll start with the easy ones:

Canvas model: Avalon's canvas model suffers from the same problem every other retained system suffers: they are hard to scale in the general case.

I worked on AutoCAD in 1985. It was and is a high performance retained system. So is Visio, another system I worked on. Every CAD system, and virtually every 3D game is a high performance, highly scalable retained system. It is true that implementing one of these systems is tricky, but it can be done, and Avalon has done it.

Ignoring Standards: I understand why someone would invent their own version of SVG or their own version of CSS: those standards can be difficult to implement, and growing your own version is a lot simpler than having to adapt an existing model to a new model.

I was around for many of the discussions of SVG and CSS. The difficulty of implementing these standards never entered into the conversations. Avalon invented XAML and its related model because it is a simpler, better integrated model. I am one of those who simply believe CSS is broken. SVG is a nice standard: I was one of the drivers behind Visio's SVG support. However, it only addresses it's problem domain of vector graphics. Integrating SVG primitives with UI elements like buttons and listboxes, either resulted in very limited system, or an awkward mess of xml-namespaces and odd syntaxes.

Consider an example like this:

<Button.ToolTip>

<ToolTip>Minimize</ToolTip>

</Button.ToolTip>

</Canvas>

</Button>

If you consider what this would have looked like if Path had to be in a different xml-namespace from Button and Canvas, and then imagine scaling this example to thousands of lines of XAML, I think the usability advantages of integration start to become clear.

Share via

Is the Canvas model scalable?

Additional resources