On Sunday, 17 March, 2002, 11:08:33, Justin wrote: JC> Chris Lilley wrote: >> 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> Persistent theme since at least mid last year. I was in one halway JC> meeting at Siggraph last year that involved 7 or 8 people, I don't JC> remember names now. Hmm, I don't recall any W3C staff going to siggraph last year, though a couple are going this year. JC> Since then, the Web3d people that also go to the W3C JC> meetings have consistently reported this. The main two that I know from JC> the web3d side are Don Brutzman and Joe Williams. Yes, I have met Don several times. I don't recall lecturing him along the lines of "SVG does x, why don't you" once, let alone repeatedly. JC> In addition, my JC> business partner was at the Web3d conference in late feb and had a very JC> long conversation with someone. IIRC it was Evan Ireland, but I'll have JC> to check on that. Ivan Herman, I suspect. >> 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> Pretty much. If you boil it down, there really isn't much different JC> between X3D and SVG. There is a scenegraph of transformations, of JC> geometry objects and material information about that geometry and of JC> user input sensors. In addition there is also a scripting system and a JC> runtime system - don't get these confused they are not one and the same JC> thing. SVG happens to use an external spec for defining runtime JC> semantics (SMIL) where X3D includes it as part of the core JC> specification. It still does the same sort of thing though - makes JC> dynamic changes to the properties defined in the original text-based JC> file format. X3D scripting is a bit more explicit than SVG, but in JC> rough, hand-waving terms, they are the same. My point was the geometry - going from 2D to 3D is not a case of "add one more ordinate" and "make matrices 4x4 instead of 3x3". I agree about other similarities arising from having an XML representation with events, scripting, etc. >> 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 (and so forth >> for the SVG-specific methods). JC> In the way we do it with X3D, there is the external world view - the DOM JC> , then there are the modifiers and externally defined content (we have a JC> system for templating new "element" types called PROTO/EXTERNPROTO) and JC> then there is the rendering engine. The rendering engine maintains its JC> own state information. How much information is communicated to "the JC> outside world" is dependent on the user of that information. JC> So we sort of do the second option - we have an DOM and an internal JC> structure. To us, CSS is just another external input to the system, JC> another structure that the core rendering engine uses during the JC> rendering cycle. It looks for changes in the CSS and applies that during JC> the next cycle, just like any other change that would come from the DOM. Okay, but changes in the DOM affect the results of the CSS. JC> For example, we have both DOM and EAI access to the internal scenegraph. JC> EAI is a high-level Java API that has nothing to do with XML. If you JC> count VRML97-defined APIs, we have four different APIs all wanting to JC> access and modify the runtime structure - potentially simultaneously. JC> That's why I say that to us CSS is just another API view into the core. OK, I see that. JC> If we now sit down and compare our spec/system to the Batik core, you JC> will notice that Batik is already 50% of the way there. GVT is the JC> rendering core, SVG DOM is the external API and CSS is another external JC> API, that may or may not be part of the DOM okay JC> (when described as XML JC> Processing Instructions rather than as a LINK). The way it is attached has little effect in practice. JC> After parsing the CSS, JC> it is just another, separate, input to the rendering engine. I agree its another input, but its not very separate. At minimum there is a high degree of crosslinking of structures. You seem to have the view that CSS is an api that makes changes to the DOM. This is not correct, it never changes the DOM (more strictly: it never alters the infoset). JC> The core JC> listens to events in the external APIs and makes the appropriate changes JC> to the visual output. In this way, the DOM has its view, the CSS has its JC> own, just as required in an earlier email. To boot, there's a hell of a JC> lot less management code needed too. I don't see how the last sentence follows from the preceding ones. JC> For SVG, SMIL is just another part of the rendering engine too. It is JC> identical to our event model, in that it is responsible for JC> synchronizing multiple different content streams over a period of time. It does that, but it does more than that. It takes the output of the CSS engine and applies a series of modifications before the result gets rendered. It has a 'sandwich' (kind of a stack) of persistent changes, so that animation of properties can also take into account asynchronous changes of the DOM tree underneath it. JC> JC> A SMIL instruction that says "start now" to the SVG is no different to JC> an external user interaction telling the system the same thing through a JC> UI component. The basic action is "start the system clock now/stop the JC> system clock now". How that instruction is initiated is inconsequential JC> and the rendering engine must treat it as such. At no time should the JC> rendering engine need to know that the start command came from a SMIL JC> document, from a mouse click on a menu item or a keyboard accelarator JC> keystroke. Start, stop, that's all you need to care about. If only it were that simple. >> 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> It depends on how the events are created and how the original source was JC> generated. If the DOM comes from some external source, we just do the JC> conversions into our internal scenegraph. Next, we look other features. JC> Does the DOM have Events capability? Yes, that was the thrust of my question. http://www.w3.org/TR/DOM-Level-2-Events/ JC> If yes, we set up mappings from the JC> DOM to our scene graph - we attach DOM EventListeners to the fragment we JC> are working from and pass the information through to the render core JC> when we see them. Right now, for the externally generated DOM, we don't JC> pass events back out that change within the scenegraph internals. Ah. See, SVG needs to do that all the time. A given, likely discontinuous piece of geometry needs to be linked back to the node(s) in the DOM so that events move correctly in the capture and bubble phases. JC> There's a bunch of reasons why, mainly inconsequential, so I'll footnote JC> those at the end of the email. JC> When the DOM is generated by us, we still take the separated stand, but JC> the DOM is now delivered all of the events. We take a bunch of JC> optimisations about when and how events are delivered. We mainly operate JC> in a stand-off mode. Our DOM works out whether a listener has been JC> registered on a particular DOM node. If there is no listener in the tree JC> looking for that event, we never deliver the value to the DOM, hence JC> avoiding the huge overheads of the DOM event cascade/bubble JC> requirements. OK, I see the benefits of such an optimisation. JC> In addition, our notification is purely "this has JC> changed". There is no value involved. The DOM maintains a dirty flag on JC> the field and then only updates the value when someone explicitly asks JC> for it. We do this because a lot of the time, our events consist of one JC> of two things - TimeSensor events and coordinate changes. For example, JC> animating a typical humanoid character involves a single set of JC> coordinate changes, where there is 1000+ 3-space coordinates as an JC> attribute of a single element (if you throw in texture information, JC> you'd triple that number at least). Turning that into an attribute JC> string every frame would be a killer for performance. OK so you take a "generate on demand" rather than a "cache everything in case" approach. Thts reasonable. JC> Now, on to user interface events - Again we act in a two-way mode. We JC> look for MouseEvent on the DOM and use that to drive objects and JC> changes. In X3D, there is really only one node type that would respond JC> to that - Anchor. We have touch and planesensors, but the way the spec JC> is worded, basically implies that the events must originate from JC> "inside" the scene graph. OK. In SVG, there are a lot more events - for example all the text-related nodes can have insert and select events; any node can have mouse hover events, etc. JC> In addition to the DOM model, we also have to deal with events generated JC> from within the rendering engine. We don't really work with user input JC> events on a generic architecture. The reason is that the various JC> rendering APIs all define how they send input events to user-land code. JC> For example, Java3D would send us AWT events through its behaviour JC> system. J3D captures those events by itself, from its rendering surface, JC> and will deliver those (potentially) in parallel with whatever the JC> external UI might deliver through the DOM interface. However there are JC> many other ways of getting user input events into the system. Again, JC> using J3D behaviours, input can come from custom input devices which JC> come through the behaviours system. In this case, we process the event JC> through the rendering engine, make whatever calculations we need to do JC> and then deliver the results to the externals of the scene graph. JC> This process probably sounds a bit odd, Its not odd, its just different to what SVG does. JC> so probably needs more JC> explaining. Within X3D, we don't deal with user input directly. There is JC> no such equivalent to "onClick" attributes. Instead, we have nodes that JC> are termed sensors. These are effectively the post-processed output of JC> the user input. So, to listen to, and then act on, a click we have a JC> TouchSensor node. This does the translation and says "the click happened JC> here in 3D space, on these texture coordinates, on this geometry". JC> (there are also equivalents of mouse over and mouse up/down). You then JC> connect the output of this sensor to a script or another node, using an JC> explicit model called ROUTEs. So, for us, having a mouse event come down JC> through the DOM would be a very rare event, as it is mostly driven from JC> internally detected sources. Yes, that's a significant difference. It makes it very reasonable for you to optimize the way you have, because only a few known parts of your rendering are event sensitive. >> Is that 100 fps with only software, or does that include hardware acceleration? JC> Hardware accel for the lowest-level rendering. Everything above that is JC> userland code. Event model, timing, scripting. At least for us, the JC> performance bottleneck is the rendering API. We take advantage of JC> multi-cpu machines by keeping the event model and rendering loops in JC> separate threads. Only on the most complex of worlds have we noticed the JC> rendering loop waiting for the event loop to finish. On average user JC> content, the render is the slow item. JC> In comparison to the SVG world, there shouldn't be any difference JC> really. Most of the lowest-level stuff is still in hardware, or at least JC> down in the operating system-specific APIs (at least from JDK 1.3 JC> onwards, 1.2 was doing pure-java software rasterisers). I must admit that I did not notice any difference in speed of 2D operations between 1.2 and 1.3. I tried 1.4 and it was slightly faster, but it was a beta and I rolled back to 1.3. I should get the release version of 1.4 But then again, if you look at a consumer graphics card from this year and from 10 years ago, the 3D side is enormously better wheras the 3D side is likely exactly the same. Few if any cards have simple alpha compositing support, for example. A common "optimisation" for Windows XP responsiveness is turning off some or all of the transparency effects. That's because they are done in software. Its kinda sad that such simple functionality is still done in software when the 3D side is so much better (for low resolution, highly texture mapped geometry at least). JC> If you started (I assume you mean the BVatik developers by "you") JC> using VolatileImage as the output source, even most of the high-level JC> operations like image transformation and clipping would be done in JC> hardware on the video card. Do modern video cards offer bicubic interpolation of images? I was not aware of that. Do you have a pointer where I could find out more? JC> Given equivalent complexity of content, I JC> would expect that SVG would end up with more software renderer usage JC> than Xj3D. (However, we could, nominally, implement SVG with an OpenGL JC> API and so have H/w accel for almost all operations). There are at least two efforts that I am aware of to try and re-use OpenGL hardware acceleration to do SVG rendering speedups. >> 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> Why do you require sync control? I may have expressed it badly. It will need to be notified of all changes to that subtree, in addition to being able to make changes to that subtree and handling event propagation. An optimization is to 'seal off' the root of the subtree and handle even propagation itself, only sending events to the main tree that move up past the root of the subtree. JC> Why can't you just be a good servent of JC> the containing application and only update your output when it perceives JC> it is a good time? Not sure what you meant by that. >> 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> Exactly, and currently Batik seems to be brushing this off as something JC> that it is not willing to cater for. In doing so it is limiting its JC> usefulness as a toolkit. I understand why you perceive that, but I am not sure its true. Certainly there are a bunch of applications that use Batik, and some of them are multi-namespace. There are other multi-namespace tools such as XSmiles that use other SVG renderers, too, so I am not sure that there is anything inherent in the SVG specification itself that precludes easy integration of other namespaces. On the other hand there is a bunch of stuff that is affected by the specs that SVG uses; so to add fooML support to an SVG implementation, the implementor needs to look at any new CSS properties it uses, and whether they are animatable, and what events are supported and whether those events are cancelable, and so forth. >> 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. JC> Can you give a reason why? I meant, there is no particular reason to conclude that Batik is "useless" in multi-namespace integration. I wasn't quibbling about the value of multi-namespace documents, quite the reverse. >>>> - 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. JC> Can you tell me why it doesn't address it? The statement is "SVG JC> requires the core DOM + SVG extension". My response is that SVG requires JC> it, but the implementation does not. The specification says "if you want JC> to interact with SVG through a set of custom APIs that is specific to JC> this content, use this set of extensions to DOM". I can quite happily, JC> and perfectly spec compliantly, access and modify the SVG content JC> through the DOM Core APIs. Yes, you can of course modify SVG content through DOM XML APIs and people do that all the time. Which is true as far as it goes, but that is not very far. in other words, your response to 'there is a whole SAVG DOM layered on top of the XML DOM and CSS OM' seems to be 'well I don't need to use that personally' which is all very nice but doesn't help the developers a great deal. JC> If you read Appendix B, nowhere does it state that support for SVG DOM JC> is required for an implementation of an SVG renderer. If you read the JC> intro, it says " The SVG DOM is builds upon and is compatible with the JC> Document Object Model (DOM) Level 2 Specification". B.6.2 quite JC> concisely states that the DOM does not need to support the full DOM2 CSS JC> implementation. Thats correct, there are two levels of implementation and CSS is optional. Implementations that do not support CSS still need to support a very small part of the CSS object model, so that certain interfaces are consistent from the user point of view whether the implementation of SVG supports CSS or not. However, the relevance of B.6.2 to Batik is zero; the appropriate section is B.6.3 JC> Nowhere does it say "the only way to interact with SVG JC> content is through the SVG DOM API". Nowhere did I say that it did. You seem to be confusing exclusivity and existence. The fact that SVG content can be modified through the XML DOM does not mean that the SVG DOM is either optional or irrelevant. You are putting up a strawman argument and I am not sure why. If you want to see what is optional and what is not, take a look at G.7 http://www.w3.org/TR/SVG/conform.html#ConformingSVGViewers JC> The introduction in 1.1 say JC> "Sophisticated applications of SVG are possible by use of a supplemental JC> scripting language" Note the word "supplemental", which means "optional". Two things. Firstly, there is a class of SVG renderer called static. It does not have to support any DOM, any animation, any scripting, any events. A typical example of this class of implementation would be an SVG-to-PDF converter, or an SVG-enabled printer. Batik, which is moving towards becoming a Conforming Dynamic SVG Viewer, does not fall into this class. Secondly, there is the supported scripting language. For Conforming Dynamic SVG Viewers. ECMAscript is mandatory and other languages are optional. Batik supports the mandatory ECMAscript and several non-mandatory alternative scripting languages. Notice the third bullet point under 'Specific criteria that apply to only Conforming Dynamic SVG Viewers': "The viewer must have complete support for an ECMAScript binding of the SVG Document Object Model." I'm tempted to draw your attention to the words "conforming", "must" and "complete" but I assume you already know what words in the English language mean, as do I. >> I would love to hear how you plan to calculate the result of a >> bounding box request without a rendering engine. JC> Quite simple. The rendering engine does rendering. The bounding box JC> calculation is not a function of rendering. It is a pre/post processing JC> step. Ok, but you are moving statements from the context in which you originally said them. Your initial point was that the SVG DOM implementation should talk to (any) XML DOM implementation and be entirely separate from the renderer. My response was addressing that. Its true to say that a small portion of a renderer could be used to satisfy some of those API calls, particularly in a static viewer. And in fact there are server-side implementations of the SVG DOM that do precisely that. Its not clear why the code would be implemented twice, other than to prove a point, as one moves to a Dynamic viewer with CSS, SMIL animation, say perhaps some animation of the width of the rectangle and a :hover style on the stroke width, the amount of the renderer that has to be duplicated increases dramatically, at which point you might as well call it a renderer. JC> Sometimes it may be more efficient to calculate the bounding box during JC> the rendering process, but the rendering process is not *required* to JC> calculate the bounding box. Granted, both about whether it required to spit out pixels and about the efficiency. >> 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> No. They are as intimate as the source materail allows. See the section JC> above. If intimacy is permitted, make use of it. If given the cold JC> shoulder, then live with it and get on with the rendering. Its not clear what that glib statement really means, in the context of Conforming Dynamic SVG Viewer. >> 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> Any application, at any one time will not be conformant. Hmm, it becomes increasingly hard to have a logical conversation about the interoperability of X3D and SVG at the specification level (my primary interest) and at the specific implementation level (also of interest) if you reserve the right to ignore any parts of the spec that you don't like when you start to loose parts of an argument. JC> The transcoder JC> API is not conformant using your rules because it generates a one-time JC> image and doesn't take into account user input or scripting. This is patently false. JC> Inlined JC> content is no different. It is just part of a bigger structure. You can JC> still be entirely conformant, but also working in unison with other JC> players on the same page. Conformance levels and multi-namespace integration are entirely orthogonal. JC> You also have to consider that conformance comes on many levels. You can JC> be conformant to the static structure, and not support runtime JC> information. Yes, exactly. Glad you see the difference. JC> You can also be conformant to various levels of runtime JC> handling - see the profiling work that is going on with SVG 1.1. Thanks for making me aware of that ;-) JC> X3D is JC> already a couple of steps ahead of you in that department. The minimal JC> profile for a mobile phone is no different to the "no runtime" system JC> too (in very general hand-waving terms). Rather too general and hand waving for spec writing, I am afraid. Earlier in the post you made some good points, but towards the end your frustration seems to have caused you to get sloppy. But then you improve again: JC> Back to your statement about being non-conformant. If you read the JC> Rendering Model of the spec (section 3), nowhere does it state that the JC> implementation must control synchronisation of the user input events or JC> anything. Yes, I clarified what was meant by 'synchronization' earlier. JC> If you read G.6 or G.7 on Conforming Interpreters, nowhere JC> does it say that the implementation must maintain control over its own JC> rendering state. All it says is that the output must be correct. How you JC> drive the internals of the animation engine to achieve that correctness JC> is not specified. In contrast, it does talk about the SVG being used as JC> a document fragment within a larger document. >> That doesn't sound too hard. Just do a deep clone of the SVG subtree, JC> But that's what I explicitly trying to avoid! I don't want to clone the JC> SVG tree. That's yet another piece of my memory you are consuming for JC> your own greediness. I want you to use my DOM, and my DOM only. Using your DOM is reasonable, using your DOM only when it does not have the required functionality is a different matter entirely. JC> How rude of you to expect that we all feel like tossing all this JC> extra memory in your directions when we already have a perfectly JC> good copy floating around in memory already. I am compelled to point out that someone who initiates a conversation by remarking that an entire implementation is a PoS has abrogated their right to accuse anyone else of being rude. So, returning to the technical issue - there are two things that can be optimized, speed and memory, frequently in opposition. Hence classic compiler tricks like loop unrolling on the one hand and sparse matrix compaction on the other. So if you have an XML document and 5% of it is little SVG sprinkles for texture etc then deep cloning is an efficient and timely way of handling things. If you have an XML document and 80% of it is SVG then deep cloning is wasteful of memory. But then, you either need a full DOM that does everything, as in Batik, or you need a DOM that adds everything else that the XML DOM does not provide and spends all its time setting mutation event handlers and passing messages between the your XML DOM part and its, everything-else DOM part, at corresponding decreased efficiency. Or, to cope with what you want, you need both sets of code and some switching logic. Hopefully I can point out that two sets of code requires an increase in memory footprint, without accusing anyone of rudeness, just RAM usage. JC> My end users will be interacting through my JC> DOM, so now I need to propogate not one, but two separte event JC> cascades/bubbles everytime something changes. How badly with that stuff JC> performance! One way to increase performance is to decrease the granularity of components that are chattering to one another. See my suggestion of deep-cloning entire subtrees, above. JC> [1] Footnote on stuff about why we don't pass events out sometimes. The JC> Xj3D implementation of XML bindings is still lagging behind the core JC> rendering API. This is because the XML DTD has been a somewhat moving JC> target. There are some concepts in VRML that are close to impossible to JC> express cleanly in XML and so there's been a lot of tossing and turning. JC> Because some of these issues are core to the way the XML interacts with JC> the rendering engine, we've let that part of the codebase lie dormant JC> for a while. In the meantime, we've concentrated on getting the JC> rendering engine and eventmodel handling correct. Once the XML side JC> settles down, it shouldn't been too hard to then catch up. Effectively, JC> anything XML has been put on the backburner, hence we haven't gotten JC> around to work with sending internal rendering events back out to the JC> DOM when the DOM is user supplied. It will be interesting to hear about your experiences with the topics discussed in this thread once you are further on the road towards implementing them. -- Chris mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
