On Thursday, 14 March, 2002, 17:49:56, Justin wrote: JC> 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. JC> Ok, well, we're in exactly the same situation as SVG is. When we talk to JC> the W3C folks they keep telling us "X3D is trying to solve the same JC> problems as SVG - SVG does it, why can't you". I would appreciate a reference to who said that, and when. JC> What they're talking JC> about is realtime rendering systems described by an XML file format. JC> While we patiently try to explain why that is not the case, let's use JC> that same argument in reverse. to wit: If X3D can do it, why can't SVG? JC> Believe it or not, the two are almost identical in structure and JC> requirements, just we add an extra dimension. Grin. Here is a 2D system, addition of a third dimension is left as an exercise to the reader..... its not really like that, is it? JC> All the XML describes is a collection elements. It really doesn't JC> matter where those elements are, or how they got created. All they are JC> is just <rect> here, <line> there Yes, that's the W3C DOM Core and XML DOM you are describing. JC> and a bunch of css stuff. Admittedly JC> X3D doesn't have CSS, but a CSS document is no different to an image, JC> video, audio file, or in our case - external prototype files. That is not a very close analogy. Since CSS does tree decoration, an implementation has to either maintain two, synchronized trees - one the raw parsed xml, one a copy of that with some extra information - or, more reasonably, maintain a single data structure that can be used to satisfy API calls for both the XML DOM and the CSS OM 9and so forth for the SVG-specific methods). JC> What you JC> do with that DOM is how you get to the next part. JC> When you are building the rendering engine, it should never, ever care JC> about how it got its source file. All you have is a DOM. It is JC> relatively trivial to build scenegraph structures with this. That's what JC> I was expecting the DOM Bridge to do. We have *exactly* the same feature JC> in Xj3D (our all-java implementation of X3D). We call it DOMtoJ3D. It JC> takes any arbitrary DOM and converts whatever it can into the X3D JC> internal rendering scenegraph - which is equivalent to the GVT code. It JC> has its own runtime engine - including external scripting engines to JC> modify the content at runtime. Xj3D manages to handle this very well JC> (our codebase is almost identical in size to Batik - 200K LoC). JC> Within Xj3D, we operate in multiple modes - Our scenegraph code does not JC> *require* a runtime environment. We could quite simply just load the JC> XML, turn it into our internal scenegraph format, and do a single-pass JC> rendering of it and never touch the scenegraph again. There is no JC> runtime engine even loaded into memory. If I wanted, I could even JC> manipulate this generic DOM and those changes, assuming the DOM JC> implementation supports DOM L2 Events, those changes appear back in the JC> scenegraph. Is that a unidirectional transfer of data? Or are there events such as user interface gestures that have to be mapped back from the scene graph to the original DOM? In other words, are events collected on scenegraph elements and then captured and bubbled on the DOM tree? JC> Also, remember that our realtime animation JC> requirements are *far* heavier than SVG's. We're running at well over JC> 100FPS, generating multiple events every frame (any reasonably complex JC> scene is generating 30-50 separate DOM event cascades every frame) and JC> it still doesn't cause us problems. Is that 100 fps with only software, or does that include hardware acceleration? JC> So, after all of this, I still cannot understand the reason why Batik JC> *requires* you to use your own DOM. You have to do everything we already JC> do and your performance requirements are far smaller than ours. What JC> happens when someone wants to render SVG content that is a document JC> fragment in a far larger, multi-spec XML file (like, say, we do)? Batik, JC> as a rendering engine, will be stuffed. No, but it will need to get sync control over part of the larger, multi-namespace DOM and make its local, enriched copy of the SVG subtree. JC> You really have to play ball JC> with all the other specs out there. For example, here is a not JC> unreasonable situation - A user creates a web page that contains a math JC> formula, a bunch of text boxes so the user can change variables in that JC> formula, and then a visualisation of that formula - both 2D and 3D. This is hardly a new scenario. JC> I JC> could see first year Math professors wanting to do this to illustrate JC> basic curve functions like parabollas and hyperbolas? My Pure Java JC> application has loaded the file using JAXP, I've handed the basic HTML JC> off to Sun's Swing HTML renderer and told it "here is the engine that JC> handles X3D namespace, here's another for SVG namespace, and here for JC> MathML". Batik is useless in this environment. There is no valid reason JC> why that should be the case. There is no particular reason that this *is* 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. JC> No it does. It requires a bunch o objects to work with that happen to JC> come from an XML document. Again, see the scripting in X3D. We have the JC> X3D DOM, otherwise known as the SAI, and all our scripting engine works JC> just fine without needing it. We use Rhino. That does not seem to address the question, at all. >> - You cannot have a generic SVG DOM implementation because it >> requires a rendering engine. JC> Again, no you don't. I would love to hear how you plan to calculate the result of a bounding box request without a rendering engine. JC> You need a bunch of classes that implement the SVG JC> interfaces to provide a structure. You also need a rendering engine. The JC> two do not need to be combined. If they are not combined, then they clearly need a fairly intimate level of communication. JC> As I've illustrated with our needs for JC> X3D, we may well want to do one-time renderers (known as a time-zero JC> loader in our local parlance). Other times I may want you to look after JC> the realtime animation, but frequently I may not want you too - I want JC> to control exactly what time that renderer goes off and updates the JC> 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). JC> Getting close, but still no need. Again, we have identical requirements JC> within X3D/Xj3D and it still works fine. You have to learrn to be JC> adaptable so that it doesn't really matter what you get as your source. JC> It if contains the stuff you need, great, if not, then scale back. If JC> you happen to get your own internal built DOM, give the end user full JC> access, if you get given a document fragment to implement, don't expect JC> to give the user everything. That seem to me to be saying that in the case of inlined SVG fragments, the implementation would be non conformant. I guess that is not very interesting to the Batik developers. JC> It can be done, and quite easily, if you architect your code properly. JC> That's reason for my comment on the J3D list. Admittedly I was venting JC> at the time because I'd just given up after 2 straight days of trying to JC> modify the Batik source to work with a standard DOM impl, That doesn't sound too hard. Just do a deep clone of the SVG subtree, and set mutation event listeners on the root of the SVG subtree so changes there can be reflected into changes in the copy that Batik is rendering, and so that events which bubble up past the top of the svg subtree get propogated on to the parent element in the main tree. -- Chris mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
