Chris Mellon wrote:
> There's not really that much to seperate. The SVG document is
> compiled into a list of drawing operations. Rendering the SVG is just
> a matter of iterating over the list and executing each operation.
Exactly. Maybe I've got SVG wrong, it it looks to me like somewhat of a
"Object model". That is, the components of the drawing are self
contained objects (though maybe dependent on other objects, like paths).
For instance, the snippet from InkScape SVG output:
There's an SVG object model in the form of the DOM, but it's for
scripting and isn't directly related to the rendering. In SVG, you
draw each element in turn, using a painters algorithm.
For example, your SVG fragment:
<rect
style="opacity:0;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1.06922174;stroke-opacity:1"
id="rect6147"
width="98.345512"
height="97.730423"
x="83.533363"
y="65.635414" />
Is compiled into this list of drawing operations:
wx.GraphicsContext.SetBrush, brush
wx.GraphicsContext.SetPen, pen
wx.GraphicsContext.StrokePath, path
wx.GraphicsContext.FillPath, path
The way my SVGDocument works is that as each element is visited during
parsing, the brush, pen, and path are created from the element
properties, and a list like this is built - it's a tuple of (callable,
arguments). Rendering the document is just a matter of iterating over
this list and making each call.
So this describes a Rectangle with various properties. Sure, you can
just immediately translate that into drawing calls, but you could also
create an object model, and then draw that. Indeed, that's how
FloatCanvas works -- everything in the drawing is an object, that has a
bunch of properties that describe it.
Currently, I'm not trying to expose an object model. SVGDocument is a
rendering interface, which takes an XML fragment and returns an object
that you can use to draw the object represented by that fragment. I
suppose it should have a better name 
The advantage of the object model approach is that you can them work
with that model -- change things, add things, move things around, etc.
Maybe the way to do it is to simply work with an XML DOM, though, rather
than create an entire other object model that is translated to/from SVG.
The SVG standard defines a superset of the XML DOM called the SVG DOM.
It shouldn't be too hard to implement.
> It's not related to SVG per se, but theres a utility in there called
> drawer.py that lets you add operations to a wxGraphicsPath and updates
> a canvas in real time. I wrote it as a way of testing wxGC
> functionality but it might make a basis for a wxGC based drawing tool.
hmm. I'll have to check that out.
> Zooming and hittesting are extremly easy with wxGraphicsContext. You
> just push a scale factor for zoom,
I can't remember why I didn't use DC.SetUserScale to do zooming with
FloatCanvas -- maybe it was the restrictions of integer coords.
GraphicsContext doesn't have that restriction, so that may be a
simplification I can use. Unfortunately, some folks have found that
GraphicsContext is substantially slower than DCs for lots of objects, at
least on some platforms.
I find wxGC to be extremely fast in the general case. I don't know
what's considered "lots" of objects but the SVG tiger has 120+ paths
and renders in a quarter of a second on my underpowered windows work
machine. Just rectangles is a lot faster. An interesting phenomena
I've noticed is that the rendering speed is directly related to the
number of pixels that get pushed - scale the tiger up to 500x500, with
it all visible on screen, and it's slower. Scale it down to 10x10 and
the rendering is lightning fast. Move it off screen so that only a
portion shows, and it's even faster.
> and you can get a hitbox from a
> path that makes hittesting trivial.
Or better yet, wx.GraphicsPath.Contains()
This just creates the hitbox internally - if you're doing a lot of
hittesting, it's less efficent than just saving the box somewhere.
However, if there are a lot (10s of thousands) of objects, calling
Contains() on each one could be kind of poky.
> Scrolling is pretty much the same as anything else.
Support by GraphicsContext.Translate() it looks like.
> a wxGC based floatcanvas would be spectacular, feel free to take any
> code you want.
I hope I'll get a chance to work on this soon, and I'll be sure to check
out your code when I do.
> Theres quite a bit of functionality that needs to be added to the wxGC
> api in order to be able to fully render SVG. Some of it's trivial,
> some will be hard or even impossible.
Let's hope not impossible -- SVG seems to be a pretty good standard, and
a good measure of what should be possible to render with WX.
There's some noise on wx-dev about moving to cairo on all platforms.
Because of it's different back ends, cairo is already basically a
vector graphics API abstraction, and it's got all the features you
need for SVG (obviously), so I wouldn't be sad at all to see that
happen.
···
On 7/3/07, Christopher Barker <Chris.Barker@noaa.gov> wrote: