Thomas E Deweese wrote:
> This shows a serious lack of knowledge of CSS. CSS effects
> everything in SVG. Lets take a look a simple piece of CSS SVG:
Yes, it effects many things. I've done a lot of work with CSS before. In
fact, at our spec meeting today it looks like CSS is going into X3D as
well. I understand the issues very well, and hence that's why I feel
confident making these comments.
> Please note that you need to support all these possible changes in
> response to scripting, and don't forget to redo the CSS cascade
> afterwords (i.e. propagate the change on fill to children, like from a
> 'g' element to it's children elements). So a change in these
> attributes on a single node often propagates down it's entire tree of
> children.
Yup. Nothing wrong with that. Quite a simple tree traversal. No
different to a 3D person deciding to change the light position or
colour. We have even harder problems - someone deciding to perform
colour interpolation or texture coordinate stuff. The performance
impacts are quite neglible in the SVG model compared to our equivalent
needs in the 3D world. For example, here are two example documents that
we want to render (leaving out all the verbose stuff and the fact we
don't have a concrete CSS spec yet, but this is something what it would
look like):
<?xml ... >
<x3d>
<head> <profile type="interactive"/> </head>
<style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
</head>
<scene>
<transform translation="2 2 3" DEF="spinner">
<shape>
<appearance>
<material style="fill:red" diffuseColor="0 0.6 0"/>
</appearance>
<box size="10 10 2">
</shape>
</transform>
<overlay location="30 30">
<svg>
<rect x="10" y="10" width="100" height="100" style="fill:red/>
</svg>
</overlay>
</scene>
</x3d>
In this example, the SVG is used to describe a 2D overlay directly on
top of the 3D window, offset at 30,30 pixels from the top left of the
window.
In a second example, we want to use SVG as a texture on that box and
animate it with our script
<X3D>
<Head> <profile type="interactive"/> </head>
<Style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
</Head>
<Scene>
<Transform translation="2 2 3" DEF="spinner">
<Shape>
<Appearance>
<Material style="fill:red" diffuseColor="0 0.6 0"/>
<Embeddedtexture type="text/svg+xml" DEF="texture">
<svg>
<rect x="10" y="10" width="100" height="100"
style="fill:red/>
</svg>
</Embeddedtexture>
</Appearance>
<Box size="10 10 2">
</Shape>
<Touchsensor DEF="ts">
</Transform>
<Script url="javascript: function gotClick(active) {
if(active)
embedrect.svg.rect.style='fill:blue';
else
embedrect.svg.rect.style='fill:red';
}"
>
<EventIn id="gotClick" type="Boolean"/>
<Field id="embedrect" type="node" value="texture">
</Script>
</Scene>
</X3D>
> So even if we were to say OK let's go ahead write all our property
> handling code twice (once for the case where the DOM has CSS support,
> so you have usable performance and once for when the DOM does not).
Can you elaborate on just exactly how you would see performance being
impacted by the separation? From what I've seen of the Batik code, it is
much less impact than us doing exactly the same thing - a colour
interpolator for example. Instead of one big monolithic block doing
everthing, small items change.
Let me again talk about how we do this within the Xj3D codebase (Xj3D is
an all-java implementation of the X3D spec). Our spec is very much like
XHTML - very heavily componentised. At the time that we start up, we
have no idea what is being rendered, or how it is being rendered. One
document could load a simple system that inlines another document. This
new document uses humanoid-animation nodes, a NURBS surface and some
GeoVRML (large-scale map of the earth stuff). Although the simple
document started and had no event model (ie no runtime code loaded,
except the code that chain-loads other files) the other code pulls in
the entire event model system. In addition, one of the components of the
X3D spec will allow to customise the event model as well. So, we can
have multiple geometry systems (largescale doubleprecision terrain code
and local coord surface) and multiple different runtime systems all
operating in parallel. In addition the scripting can be screwing around
with our runtime structures on the fly too - for example adding or
removing geometry, changing properties.
In order to accommodate these requirements we build a collection of
component systems. We have scripting engines, file parsers, scenegraph
builders and traversers, raw geometry implementations (rendering engine
such as OpenGL or Java3D). These pieces are assembled on the fly in
response to what the user is doing to the scene. In addition, the
low-level parts of the toolkit allow you to control everything. For
example, our equivalent of your Transcoder API never loads the runtime
engine. It loads one parser for the input file type (X3D has both XML
and a "traditional" UTF8 encoding, we also should be able to handle
binary input such as MPEG-4 BIFS encoding), a factory that builds the
classes of the scenegraph structure (your GVTBuilder), a scene graph
traverser, and and output generator. Each of these are pluggable and
assemble into different parts. For example, I could use an OpenGL
renderer for our intermediate scene graph representation if I really
wanted to. There's no point, so I just use our "in memory" scenegraph
implementation instead which is sort of equivalent to the GVT
GraphicsNode derived classes. As input to this system, our DOM could
come from our parser, from JAXP's system or even from the Batik
DocumentLoader. In this example, I never even bothered firing up the
runtime engine because I knew I was never going to need that. By
contrast, when building a BridgeContext, it is already assuming a full
runtime DOM model (the Batik SVG DOM implementation), including events
and renderer.
As an exercise to check myself, I just sat down and wrote a static image
output system for Xj3D. We didn't have this. If I just used a static
Java3D renderer and Sun's JPEG codec, it took me 1 hour to right.
Effectively the architecture allowed me to write something that allowed
me to embed X3D content inside SVG content as a static image that
supported multiple different file formats as input and dumped a single
output.
> There are other things in SVG which are even worse. Let's take a look
> at the use element:
Both SVG and X3D have the same construct - in X3D's case, it is termed
DEF/USE. Define an object and then USE multiple copies of it. This
creates shared parts of the scenegraph to reduce file size and, from a
3D rendering perspective, allows us to send one set of vertex/texture
coordinate systems to the video card instead of multiples. When used
correctly, it is actually an optimisation device, because within X3D,
you share things at much lower levels - materials/appearance level -
which basically means a shared stylesheet in the 2D world (I'm thinking
XHTML as well as SVG). For us, using shared stylesheets allows other
optimisations, such as state sorting for the rendering pipeline so that
we minimise rendering context swaps, which hurt performance. Once you
boil the issues down, there is absolutely no difference to what you need
to do with stylesheets compared to what X3D does already (and 3D
graphics in general for at least the last decade).
You make one more example of CSS usage - someone removing an overriden
style sheet on the fly. That is no different to one of our users
deciding to remove a shared material node on the fly. It happens, we
have to go back to the local defaults. It's quite simple to deal with.
The internal scenegraph is the manager, not the DOM.
> The real kicker here is that the referenced elements must appear
> as if it were cloned into the host DOM tree (for event propagation
> etc) but must remain unseen by normal DOM traversal (getElementById,
> checking children of use etc).
>
> I just don't know how you would build this on top of a standard
> DOM implementation.
I think this is where the main problem lies with the SVG toolkits in
general (I've also done evaluation work of the CSIRO toolkit as well).
You are assuming that the DOM is the scene graph. In reality, it isn't.
The scene graph is a collection of rendering instructions, of which DOM
is just one view into it. Batik is already part of the way into that
structure - GVT forms an internal scenegraph renderer, not DOM. SVG code
tends to confuse this issue and just assume the two are the same, when
they don't need to be. Another view into that scene graph is CSS. An
output of that scene graph is a Swing canvas, or an AWT Image or even
the DOM.
That's my problem with Batik at the moment. It is a toolkit that is part
of the way to being a generally useful thing. Right now, the assumptions
about how it is being used are very narrowly defined in scope. As a
first cut, it is reasonable. You could do better. I'm hoping to convince
you of a way of doing better so that you will end up with more users and
more different ways of using the toolkit.
Just to throw one more sweetener into the way it is structured
currently. JDK1.4 introduced a new Image type - VolatileImage. This
image is one that is kept on the video card. There are a number of huge
performance benefits to using this - particularly in pixel manipulation.
Most of these performance benefits are not exposed to the end user -
someone using Graphics2D. They can still use the same operations and as
far as the "rendering" code is concerned, it never knows the difference.
SVG does large amounts of image manipulation - clipping, filtering,
transformations - that would benefit from the performance offerings of
VolatileImage. Right now, Batik offers me no way of rendering to a
VolatileImage, I must stay with the old, stodgy BufferedImage. Shouldn't
I be able to create my own Image, hand that to Batik and say "go render
here". I want to load the XML file once and then throw it away. I'm
never going to use it again, why should I need to keep all that extra
cruft around for a situation that will never happen.
> FYI, you are dead wrong about Batik assuming you will use a
> transcoder or a Swing component or always doing lots of caching and
> having tons of threads
Ok, so what design goals is it fulfilling? What assumptions about the
output device is it making? It is certainly not obvious from the public
webpages. I can guarantee you that it certainly was not designed with 3D
graphics intergration in mind, nor was it designed with the idea that it
might form one component of a mixed-content file format.
> when it wasn't immedately obvious how to do what you wanted you
> assumed we were the idiots (couldn't be that the issues are deeper
> then YOU would understand in two days poking around could it?).
I understand the issues quite well. I've been floating around in this
world for quite a long time. One of my projects wrote an SVG render
waaay back in the days of when it was early draft specs (1998 IIRC). You
also mistake what my assumptions about Batik were. I am frustrated that
a toolkit that is already so large didn't already assume that people
were going to try to do "non-standard" things with it. I think that the
architecture never considered these usages.
Believe it or not, SVG and X3D are very similar in terms of
specification architecture and therefore implementation requirements.
I'm just very disappointed that the most popular codebase hasn't chosen
to be as flexible as possible - particularly with the amount of
resources thrown at it. For comparison, Xj3D is almost exactly the same
size (we just cracked 200K LoC), was written in half the time (1 year)
and by only 2 people. It also uses and intergrates many more
technologies into it and is way more flexible (for example, Xj3d can be
show as an applet in a webbrowser and also in a couple of million dollar
SGI-driven CAVE with custom-made input devices). I would dearly love to
use Batik, today, I can't.
As for the questions, I did spend a lot of time perusing the various
resources of the list - archives, sample code and even the source of
Batik. For example, as I explained in the original java3d list email,
your standard answers for how to do stuff is not usable for us. The
Imagetranscoder is useless in a 3D environment to generate standard
textures. Anyway, I'll write a separte requirements doc email for what
we need from the 3D graphics perspective. I am hoping that you will
consider these in the architecture as you go through 1.5. For us, an
ideal situation would be to demonstrate at Siggraph in July this year
mixed 2D and 3D content, with either SVG as the parent document or X3D
(or XHTML if we could!).
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
