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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
