xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Couch <jus...@vlc.com.au>
Subject Re: GVTBuilder error with custom DOMs
Date Thu, 14 Mar 2002 16:49:56 GMT
Vincent Hardy wrote:


> DOM is an *API* that implementations need to expose. There are generic
> implementations of that API, such as the ones provided by Xerces or 
> Crimson, and they allow generic manipulation of XML content through
> the DOM API. However, this is limited to generic manipulation and 
> it is not enough for what is required for SVG processing. 

Ok, well, we're in exactly the same situation as SVG is. When we talk to 
the W3C folks they keep telling us "X3D is trying to solve the same 
problems as SVG - SVG does it, why can't you". What they're talking 
about is realtime rendering systems described by an XML file format.

While we patiently try to explain why that is not the case, let's use 
that same argument in reverse. to wit: If X3D can do it, why can't SVG? 
Believe it or not, the two are almost identical in structure and 
requirements, just we add an extra dimension.

All the XML describes is a collection elements. It really doesn't
matter where those elements are, or how they got created. All they are 
is just <rect> here, <line> there and a bunch of css stuff. Admittedly 
X3D doesn't have CSS, but a CSS document is no different to an image, 
video, audio file, or in our case - external prototype files. What you 
do with that DOM is how you get to the next part.

When you are building the rendering engine, it should never, ever care 
about how it got its source file. All you have is a DOM. It is 
relatively trivial to build scenegraph structures with this. That's what 
I was expecting the DOM Bridge to do. We have *exactly* the same feature 
in Xj3D (our all-java implementation of X3D). We call it DOMtoJ3D. It 
takes any arbitrary DOM and converts whatever it can into the X3D 
internal rendering scenegraph - which is equivalent to the GVT code. It 
has its own runtime engine - including external scripting engines to 
modify the content at runtime. Xj3D manages to handle this very well 
(our codebase is almost identical in size to Batik - 200K LoC).

Within Xj3D, we operate in multiple modes - Our scenegraph code does not 
  *require* a runtime environment. We could quite simply just load the 
XML, turn it into our internal scenegraph format, and do a single-pass 
rendering of it and never touch the scenegraph again. There is no 
runtime engine even loaded into memory. If I wanted, I could even 
manipulate this generic DOM and those changes, assuming the DOM 
implementation supports DOM L2 Events, those changes appear back in the 
scenegraph. In addition, if someone makes changes in the internals, say 
using a script, those items appear back in the DOM and also generate the 
appropriate DOMEvent too.

At the next stage of use, you can add a runtime engine. The runtime 
engine works on our internal structures. Once that internal structure 
has been loaded, the runtime structure then takes care of the animation 
in realtime. Sometimes that animation may be a 3D renderer, in other 
times it may be a server-side system for generating X3D content on the 
fly (sound familiar?). Either way, it doesn't matter. The runtime engine 
still operates in a way that it doesn't care who or how I the DOM was 
loaded in the first place. Also, remember that our realtime animation 
requirements are *far* heavier than SVG's. We're running at well over 
100FPS, generating multiple events every frame (any reasonably complex 
scene is generating 30-50 separate DOM event cascades every frame) and 
it still doesn't cause us problems.

So, after all of this, I still cannot understand the reason why Batik 
*requires* you to use your own DOM. You have to do everything we already 
do and your performance requirements are far smaller than ours. What 
happens when someone wants to render SVG content that is a document 
fragment in a far larger, multi-spec XML file (like, say, we do)? Batik, 
as a rendering engine, will be stuffed. You really have to play ball 
with all the other specs out there. For example, here is a not 
unreasonable situation - A user creates a web page that contains a math 
formula, a bunch of text boxes so the user can change variables in that 
formula, and then a visualisation of that formula - both 2D and 3D. I 
could see first year Math professors wanting to do this to illustrate 
basic curve functions like parabollas and hyperbolas? My Pure Java 
application has loaded the file using JAXP, I've handed the basic HTML 
off to Sun's Swing HTML renderer and told it "here is the engine that 
handles X3D namespace, here's another for SVG namespace, and here for 
MathML". Batik is useless in this environment. There is no valid reason 
why that should be the case.

>    - SVG requires implementation of the SVG DOM which has a lot of
>      extensions compared to DOM Core. This is not supported by generic
>      implementations.

No it does. It requires a bunch o objects to work with that happen to 
come from an XML document. Again, see the scripting in X3D. We have the 
X3D DOM, otherwise known as the SAI, and all our scripting engine works 
just fine without needing it. We use Rhino.

>    - You cannot have a generic SVG DOM implementation because it
>      requires a rendering engine. 

Again, no you don't. You need a bunch of classes that implement the SVG 
interfaces to provide a structure. You also need a rendering engine. The 
two do not need to be combined. As I've illustrated with our needs for 
X3D, we may well want to do one-time renderers (known as a time-zero 
loader in our local parlance). Other times I may want you to look after 
the realtime animation, but frequently I may not want you too - I want 
to control exactly what time that renderer goes off and updates the 
scene graph.

>      The SVG DOM implementation needs
>      to have to have access to the rendering
>      engine to be able to implement the SVG DOM (e.g., for returning
>      the bounding box of an object). 

Getting close, but still no need. Again, we have identical requirements 
within X3D/Xj3D and it still works fine. You have to learrn to be 
adaptable so that it doesn't really matter what you get as your source. 
It if contains the stuff you need, great, if not, then scale back. If 
you happen to get your own internal built DOM, give the end user full 
access, if you get given a document fragment to implement, don't expect 
to give the user everything. Let me, the end user programmer, be the 
judge of what is acceptable to my application, not your library. If I 
want to cut off my own arm, let me.

It can be done, and quite easily, if you architect your code properly. 
That's reason for my comment on the J3D list. Admittedly I was venting 
at the time because I'd just given up after 2 straight days of trying to 
modify the Batik source to work with a standard DOM impl, but the basic 
criticsm remains - the architecture of Batik is poorly thought out if 
you want it to be more than just swing components and writing out JPEG 
files.

If you want, and am quite happy to work in the development side of this 
to restructure the Batik architecture so that it will be useful to a 
wider range of people - including those of us over in 3D land. I want 
Batik to be useful, today it is not. There is the rest of the world out 
there, and it needs to play nice. I've done it once with a piece of code 
that is almost identical in requirements to SVG, it's not hard to 
transfer those lessons across. Indeed, I believe most of it can be done 
under the covers without upsetting the "end user" API.

> Note that there is a utility to convert any DOM tree to our
> implementation:
> 
> org.apache.batik.dom.util.DOMUtilities.deepCloneDocument()

Tried using that and it was barfing on a number of things. I'll have to 
go back and fix my source back to standard again to get you some error 
messages (BTW, I tried to sign up for Bugzilla, but stull hasn't sent me 
a passwd yet.)


-- 
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message