Code checked-in

I've just this minute put both the original XSLT code and the new XQuery code into the X-Reyes Google Code SVN repository.

Back in business

I have recently been working on another implementation of the Reyes pipeline, this time I'm using XQuery. So far I have the TIFF serialiser and I've gotten as far as the read, depth-sort and bound steps. There is an X-Reyes Google Code project and soon I'll be uploading both the original XSLT code plus the new XQuery stuff too. As this is very much a Functional Programming approach the XQuery code will, until XQuery 1.1 comes out, only run on Saxon-EE or MarkLogic Server.

Of beginnings, endings and syncbases

Given that x-reyes will generate animated sequences, it is quite obvious that those sequences are a fixed set of frames. Therefore, the fancier interactive aspects of SMIL, like mouse events and/or wallclock times, will not be required.

To that end (no pun intended), the @begin and @end attributes will support syncbase values of the following form:

syncbase-value ::= ( Id-value "." ( "begin" | "end" ) ) ( S? ("+"|"-") S? Clock-value )?

The begin and end events of named animation elements (set, animate, animateMotion, etc) is a very powerful feature of SMIL that should be supported and for that matter utilised where possible. After all, everyday life is a connected sequence of beginnings and endings, that may be offset from each other, but they are all connected to synchronizing base events. Just consider a simple walk cycle!

The svg:set element...

On the face of it, the svg:set element does not seem to be as much fun as the others. In fact you can achieve the same effect by setting the @calcMode to 'discrete' which has the effect of not interpolating between the extremes.

Anyway, I now have support for svg:set.

I was supposed to be doing svg:animateMotion next but svg:set seemed easier by far than the whole motion path, keyPoints, keyTimes and keySplines scene!

The svg:animate element

As of this writing I have support for the following properties of the SVG animate element:

* @attributeName
* @begin = clock-value
* @dur = clock-value
* @end = clock-value
* @fill = (freeze|remove)
* @from = length without units!
* @to = length without units!
* @by = length without units!

I do need to deal with @from/@to values that decrease, and for that matter @by values that are negative.

After that I'll be looking at svg:animateMotion.

Drifted into the world of animation

One aspect of implementing a Reyes render would be that ability to render animated sequences. To that end I have 'branched-off' into the world of animation, or to be more specific SMIL - the Synchronized Multimedia Integration Language. SMIL (pronounced Smile) is a 'framework for incorporating animation onto a time line and a mechanism for composing the effects of multiple animations'. Although a W3C recommendation in it's own right it is also the animation component of SVG.

Given the work I have done to-date with X-Reyes you wont be surprised to here that I have started implementing a SMIL interpreter using XSLT. The idea being that the XSLT transform(s) take an SVG graphic, with inline svg:animation elements, and generate the 'inbetweens' for each animated primitive. There is an SVG/JavaScript test harness that allows you to run, pause, step forward/backward and stop the animated sequence using conventional video playback style buttons.

The next step would be to generate a sequence of whole graphics, one for each frame of the timeline that can be subsequently fed into the X-Reyes render to generate the required frame images. In an ideal world I'd by generating an animated GIF but X-Reyes only supports TIFF at present.

A little snip here, a little snip there

In order to pave the way for the next phase, I have done some trimming of the data structures used within the X-Reyes.

The chief culprit was the use of the svg:metadata element to store additional data (metadata if you like) about the primitives. I had used an:

<xr:bbox top="0" right="16" bottom="16" left="0"/>

element to store the bounding box of each primitive (and micropolygon). This, as I'm sure you can imagine is rather verbose. So I have done away with the svg:metadata element and now use an:

xr:bbox="0 16 16 0"

attribute instead. This has reduced the memory required to process an image by a third.

Sweet!