GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

G'day Folks,

Popping my head out of the woodwork here to ask a few questions about 
the Batik implementation, and to point out a bug or two. This one is a 
bug report, advice request to follow in the next email....

The bug: - The GVTBuilder crashes if I pass the code a Document instance 
created by the default JAXP parser. The code in GraphicsNode assumes 
that you will be getting a DOM Document that happens to support the 
Views extension. This is not always the case - we use our own custom DOM 
builder (we're creating DOM Level3 documents and providing our own DOM 
implementation). The crash we get is this line:

public GraphicsNode build(BridgeContext ctx, Document document) {
    // set the media type
    AbstractViewCSS view;
    view = (AbstractViewCSS)((DocumentView)document).getDefaultView();

System - JDK 1.4.0FCS, Batik 1.1.1 binary download.

I'm finding that the Batik code is making a hell of a lot of assumptions 
about who generated the DOM instance for it. In general, the testing 
looks like you've only assumed that you're using the Apache DOM 
implementation (probably crimson by the looks of the included download 
JARs). The code should be more rigid by first checking what capabilities 
the Document has that is being passed to you. ie, You need to insert at 
least these lines:

DOMImplementation impl =  document.getImplementation();
if(impl.hasFeature("views", null)) {
    AbstractViewCSS view;
    view = (AbstractViewCSS)((DocumentView)document).getDefaultView();
    ....
}

Either that, or state up front in the documentation that the generator 
of the document must support XYZ features for it to be usable with Batik.

-- 
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

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

Chris Lilley wrote:
> Ivan Herman, I suspect.

Ta. I had Ivan in my mind, and kept thinking Ivan Sutherland and knew 
that wasn't right :)

> My point was the geometry - going from 2D to 3D is not a case of "add
> one more 

Ah. Ok.

> 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.

True, but those changes don't have any effect until that next render 
cycle. Effectively all the changes are batched together and then the 
render engine just applies the lot during the next frame.

> 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).

Ok, I probably didn't really explain myself that well. I understand that 
CSS is not an API, but rather a decorator. An API can change the CSS 
(Such as DOM-CSS) and then those changes are propogated into the 
rendering core. In this way, it is not altering the DOM, but the 
renderer still needs to understand state changes in both - including the 
addition and removal of the complete CSS.

On one point though I disagree. There is no crossing-linking between the 
strucures. A CSS can exist standalone of the XML document, just as an 
XML document can exist separately from a CSS. One does not make changes 
to the other. The linking is only made at runtime, and not by the DOM or 
by the CSS in-memory representation. The linking is made by the 
rendering engine. If nothing renders, then the link between the two is 
only whatever the external viewer (talking about an arbitrary piece of 
userland code here)  decides to make of it.

> 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.

If you consider each input to the rendered output, then DOM and CSS are 
two independent items. At the moment, the Batik rendering core assumes 
that they are inseparable, which is a fundamental point of disagreement 
here. If you treat the rendering core as just that, and both DOM and CSS 
data structures as separable items that make occasional (in the grand 
scheme of things) modifications of the rendering state of the core, then 
the management code in the core becomes almost non-existant. That is, it 
can continue to operate and render without ever needing to refer to 
whatever generated it. If the DOM never changes, why should the render 
core need to refer to it every frame? That's an awful lot of extra 
overhead there.

> 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.

Sure. I'll have to defer on that point. I've used SMIL as an end user a 
bit but have never implemented a rendering engine that is driven by SMIL 
definitions. (FWIW, we're also getting some comments from one of our 
customers to work in SMIL support to X3D too! ARRGGGH! Too many things!)

> 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.

Sure. I was just hand waving to illustrate the conceptual point. That 
point is that the render engine goes on its own merry way maintaining 
its constant state until prodded from the outside. Consider it Newton's 
3rd law applied to software. SMIL just becomes another thing that can 
upset the constant state that the renderer wishes to remain it.

> 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.

But do they? Apply the old cliche - If a tree falls in the forest and 
there is nobody around, does it make a sound? If you have no listeners 
on your DOM, do you need to propogate that event into the DOM from the 
renderer? Just like physics, if you observe the action, you change the 
state of the system. That's the way our DOM implementation works. If 
nobody is listening, we never pass the events through. That leaves us 
extra CPU head room to do stuff like render faster (DOM event 
propogation is a really nasty thing in performance/efficiency terms and 
doesn't translate across to realtime rendering systems at all well). So, 
from a comformance perspective, as soon as you attach a listener to the 
DOM tree to check that events are being propogated, you see them. As 
soon as you remove the listener, we stop sending them. We pass the 
conformance test and you get a nice high-performance, decoupled 
architecture.

So, you say - how do you know if someone is listening or not? Well this 
is where we come back to this architecture of dealing with DOMs from 
various sources. If the DOM comes from our custom source, then we can 
monitor exactly when and what someone is listening for. We wrote the 
code, so we added the hooks for it. That one's easy to deal with. What 
about the case when we are using a user-supplied DOM implementation? In 
this situation we assume that we're part of a mixed-media document 
anyway, and so someone is going to want to know about it. Therefore we 
propogate all events all the time. It has a performance impact, but 
that's not a problem. Our assumption is that if we're given a DOM to 
work with, there is a very high probability that they will be managing 
the rendering updates too - effectively our renderer is embedded in a 
bigger page space and so that pagespace will be managing the repainting 
schedule. Therefore, and performance degredation due to DOM event 
cascades/bubbles are not going to be as much an issue as before. The 
performance bottleneck will not be our renderer, but the application's 
page space update manager.

> 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.

How do those events get generated in the first place? What piece of code 
determines that "I should propogate a select event into the tree now"?

> 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.

Actually, you'd be surprised how much of the entire scene graph is event 
sensitive. Many different sensors types exist - such as visibilty, 
proximity and collision that are not activated by user input, but still 
generate eents that get sent through the entire scene graph. A fairly 
normal approach is to place a touch sensor on the root node of an entire 
object hierarchy - say a H-anim character. In addition, there is a bunch 
of capture-like semantics in X3D too where you can nest sensors. You 
have to traverse the entire render tree to work out who should receive 
the event. So while we are slightly different in terms of the type of 
events, the amount of information that could traverse up and down the 
tree is close.

> 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

Err.. next set of comments are Sun JDK implementation-specific. If you 
weren't using the Sun code, then this is probably inconsequential 
because other JVM providers may have implemented the code differently.

1.4 feels a bit faster, some of the time. 1.3 was significantly faster 
than 1.2 if you were doing a lot of image manipulation operations. At 
the time Sun wrote the 1.2 APIs in pure java - right down to their own 
implementaiton of Breshnam line rasterisation. This was a huge source of 
complaints at the time because 1.1 used native APIs and there was quite 
a massive performance impact. Many developers stayed away from 1.2 for a 
long time because of this.

With the move to 1.3 Sun moved their implementation back to using the 
native APIs of the underlying OS. For simple actions like lines and 
circles, there wasn't that much difference, but once you started doing 
heavy work like image convolution operations, there were very 
significant performance increases.

Going to 1.4, I don't believe there are many major performance 
optimisations on the rendering/image manipulation stuff. The major 
performance improvement will be with the use of the new APIs and new 
image formats. In particular, making use of DataBuffers and 
VolatileImage to make sure that a lot of the image loading and then 
manipulation code never makes it to into the Java code will have 
significant performance impacts. There's a nice JMF/J3D demo that 
illustrates this floating around in the bowels of the Swing Connection.

> JC> If you started
> 
> (I assume you mean the BVatik developers by "you")

Yes. Make that a general assumption about all of my mutterings.

> 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?

I remember at least a bunch of the 3DLabs cards do. I've got some 
pointers in one of their presentations, but we're under NDA for that. 
Basic hint is stuff mainly about OpenGL 2.0. As for other video cards, I 
haven't been paying attention much over the last six months. Been too 
busy just keeping up with the 3D side of the house.

Hmmmm.... just thinking about it, even if you didn't have it as a native 
operation on the hardware, implementing it as a pixel-shader would be 
pretty trivial. You'd get close to hardware accel, but obviously 
requires per-machine, per-video card setup routines that are well and 
truly outside the "pure java" world.

> There are at least two efforts that I am aware of to try and
> re-use OpenGL hardware acceleration to do SVG rendering speedups.

Oh, that would be nice! Either of them Java based?

> 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.

When the SVG renderer is working as a sub-component of a larger page 
space, it will need to react to the page space's repaint requests. The 
containing page-space becomes the arbiter of when the SVG renderer 
should run. It will have its own buffering schemes. That's part of the 
problem that we face with trying to use Batik within an X3D/Java3D 
environment - the J3d renderer has its own timeschedule. We can only 
push a new texture to the screen/video card during the time when J3D 
tells us it is OK to do so. When we get this request, the renderer runs 
around looking for what has changed - it would then call the SVG 
renderer and tell it "render now, in these clip bounds". We honestly 
don't care what happens to the SVG content in between, because it will 
never be visible to the user. If a mouse event is found to happen over 
the top of the SVG content, we'll pass that in by whatever means is 
required (posting an event to the the doc fragment that represents that 
texture probably) However, we do care if we happen to catch the SVG 
renderer mid-frame. That's why we (as any other container application 
would) require complete synchronisation and clock management  over the 
renderer. We'll tell you when is a good time to render, not when you 
think is good.

If you take the reverse situation - an X3D document fragment embedded 
within an SVG parent document, Xj3D will already handle that. The 
toolkit provides APIs and interfaces that allow you to be the clock and 
render controller and synchronisation. If you tell us to paint, we'll 
paint and we won't paint when you don't want us to.

> 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.

I agree with you on the second part, and only partially on the first. 
Sure, it is possible to make Batik work in a mixed-content system, but 
it is *hugely* inefficient in doing so. Just the overheads of 
maintaining multiple DOM trees alone is a killer. On top of that, the 
way Batik goes off and creates its own threads and caching mechanisms is 
positively anti-social in bigger application environments. For us, in 3D 
graphics land, that's like the absolute, ultimate turn-off. 3D graphics 
is very rarely multi-threaded - typically limited to 2 threads. The 
reason for this is the need to be able to precisely control system 
resources and synchronisation of state. There are other major turn-offs 
too, like the way image handling is done - either at the transcoder 
level or internally in the rendering process. There's some hideously 
inefficient stuff going on in there. Garbage collection is a realtime 
renderer's worst nightmare.

> 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.

Do you really need to? For example, if I embedded an X3D document within 
SVG, why should you care about what CSS properties I use. If they effect 
me, I'll update my render core, and then I'll wait for you to tell me to 
render. Really, a good component-based API should provide the end user 
of registering a namespace and the renderer for that namespace. When 
content is detected from that namespace in the DOM tree, create an 
instance of the nominated renderer, and then act as a supervisor. Tell 
me when I need to update and then you take care of the image composition 
that needs to be done. I (being some component registered with the batik 
rendering engine) have to conform to your component API, and you spec 
what my interface will be (typically a method that has the rendering 
surface size, the rendering surface, the clip bounds and the current 
time/clock tick as parameters and maybe a rendered image as the output). 
   Since you're the one in control, you the composite my output image 
into the overall output and everyone's happy.


> 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.

I'll disagree with you on the first point. That's how we got into this 
conversation. I believe, for a particular class of applications, Batik 
is useless. I'm trying to get that fixed :)

> 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.

Why doesn't it help them? It is a loud message to say that there is at 
least one class of applications, and XML-based specifications, that 
really don't care, and probably don't actually want that DOM hanging 
around. If you can build us a toolkit that can throw it away, we'll be 
very happy and will use your project in ours. blah, blah, blah.

> However, the relevance of B.6.2 to Batik is zero; the appropriate
> section is B.6.3

Again, I ask why? I would like to supply you with my user agent that 
does not have CSS support. Why are you not interested in supporting me?

> 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.

Que? The whole point of this discussion is batik developers saying "the 
core rendering engine for any SVG renderer cannot exist without the 
existance and very tight coupling to the SVG DOM - and one particular 
implementation of it at that". I'm point out the fallacies in that 
argument. That is hardly a strawman.

> 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."

Yes, and that has nothing to do with the rendering engine. What defines 
a viewer? A viewer must support it - it in no way implies that the 
viewer must supply it. Two very different concepts. If I pass you a DOM 
that is prebuilt and does not contain the SVG-DOM feature, you can still 
be conformant viewer. You have to support it, not implement it.

Ah, you say, but what about the "ECMAscript binding" bit? If I don't 
implement that, then how can we be conformant? Well, again Xj3D can be a 
case study for you. Our scripting engines, again, a required feature by 
the specification, do not work inside the DOM. They are another adjunct 
to the rendering engine. When I fire up the Context for Rhino, I pass it 
in a collection of prebuilt objects. At the root, is one of those nodes 
that the ECMAScript code is looking for. As an implementation of the 
Context, when I get an ECMAScript [[get]] action, I run off to the 
rendering engine and attempt to find what you are talking about. Then, a 
bunch of wrapper objects are created as you start walking the object 
heirarchy. Each [[get]] request (which manifests itself as the void 
get(int, Scriptable) method of the Scriptable interface) just goes back 
to the rendering engine for the right information. Any writes to those 
objects get propogated into the rendering engine core and then the 
script exits. At no stage does the script ever use or touch the 
"external" DOM. Even though the script is defined inside that DOM, it 
operates in its own separate context that lives off the side of the 
render engine. In this way, you can have an externally provided DOM that 
does not implement the SVG feature set, and yet still have scripting 
that is conformant.

> 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.

Yup, and you don't seem to know how to read specs and weasel out of them 
:) In all honestly, I've written one ISO spec, reviewed a couple of 
others (MPEG-4 being the most well-known) and contributed huge numbers 
of reviews and modifications to the main VRML spec. I understand 
implicitly what words of a specification say and mean. I also understand 
what they don't say. Building useful toolkits are as much about reading 
what was not said in the specification as reading the things that are 
said. I believe the Batik developers are concentrating too much on the 
later and not enough on the former. If I could get you to concentrate 
more on the former and make those architectural changes then you would 
still be completely conformant and be much more useful to a wider audience.

> 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.

Not at all. Think of a null renderer as a piece of code that provides 
the basic data structures for all other renderers. There's no need to do 
all the field management stuff twice, so just combine it into a common 
set of base classes. Or, as we're starting to do with the Xj3D project - 
the Java3D renderer extends the basic null renderer to include output 
capabilities. There's no need to duplicate the basics, just add in the 
bits that are specific to your particular output device. We do this in 
Xj3D. Our null renderer still runs just like a real application - 
including realtime modifications and scripting. Because we've decoupled 
the various parts of the architecture, the scripting engine doesn't care 
how the objects got loaded, just that they did. It doesn't care what the 
renderer is either. It just works. Looking through the SVG spec, there's 
not that much that you need to do. Bounding boxes are trivial to 
calculate without needing a renderer. Images have their information 
supplied, various shapes do, all you really need to do is work out the 
total glyph bounds for the text items, and that can be trivially done 
without needing a renderer too.

> 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.

See point above. Conforming can be implemented and provided with any 
user-given DOM, regardless of whether that DOM supports the SVG features 
or not.

>>>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.

Eh? I'm not ignoring it at all. I'm pointing out there are various ways 
of interpreting the written word. There are also times where some users 
may not care about conformance, or they only want a subset of 
conformance. Say batik says "I'm implementing a Dynamic SVG Viewer", I 
want to come along and say "no, I don't want you to be a dynamic viewer, 
static only is fine please".


> 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.

I disagree, for the reasons stated earlier - the Batik developers are 
saying that I cannot have mixed-content integration, because then they 
can't be conformant. Which one is it to be?


> 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.

Not really. See points above. It doesn't have to have the required 
functionality. It can still stay conformant.

> 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.

Well I must have missed a smiley there somewhere then. I shay, that wash 
a joke shon, a joke! In addition, calling something crap is not being 
rude, it is an opinion. If you are offended by an opinion, so be it. 
Thicker skins are needed. I'm not going to retract that, and as we go 
further through this discussion it only confirms my original opinion. If 
someone took a look at my code and called it crap, I would love that! it 
means that there is a user that is prepared to look at it, weigh it up 
and then make an opinion. If I can get some reasoning out of that, then 
it will only make my code better. This is a public invite for all of you 
to take a look at any and all of my public code, which has to be well 
over a half a million lines by now, and give me a technical review of 
what I've done. Tell me honestly what you think of it. There's at least 
one piece of code that is central to this discussion now. Go read, 
comment, try to understand, offer me an opinion. Good or bad, I don't 
care. If you only ever want to hear good news, I might as well leave 
now, because I ain't gonna offer it with the code/project in the state 
it is. At least I'm not like most people - I'm here discussing stuff 
trying to get improvements made, rather than just dissing it loudly and 
often in a public forum and not being perpared to do something about it.

> 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. 

Knowing apriori is a wonderful thing. We never know that, so we build 
the toolkit appropriately. All I can say today is that deep cloning, 
even for the 5% case is extremely wasteful of both memory and other 
resources, just as much as the 80% case.

> 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.

The only thing that isn't implemented on our XML side currently is the 
talkback from the rendering core to a user-supplied DOM. It's actually 
quite trivial to code up, because all the structures are in place. All 
the rest of our DOM implementation is complete and works very well with 
the core and mixed access modes and content models (for example, we can 
have someone parse a VRML-classic encoding file and present that as a 
DOM to an outside user. What we haven't done is updated the DOM-Extended 
API (Called SAI, which is equivalent to SVG-DOM) to the latest versions 
of the specification. The "old version" works fine with the core and all 
that, just if someone tried to compile against the new libs, they'd get 
errors due to slightly different structures. The main issue is just 
which tags are in the content model. Hence, I didn't think it was worth 
my brain context-swapping to build the integration code when there were 
other more outstanding issues to be dealt with.

As for the mixed-content handling, well we're at an impass currently. We 
wanted to work on that, but the SVG toolkits that we can find won't work 
in such a mode in a way that would render anything faster than a beetle 
crawling across the page. We'd like to fix that if we can. However, we 
might have to go find another spec to play with where the toolkits are a 
bit better organised or drop the thoughts entirely.

-- 
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

Re[2]: GVTBuilder error with custom DOMs

[Chris Lilley <ch...@w3.org>]

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:chris@w3.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Giles <gi...@oz.net>]

Chris Lilley wrote:

>On Sunday, 17 March, 2002, 18:27:18, Giles wrote:
>
>The correct solution seems to be to layer the additional methods and
>objects on top of, rather than as a replacement for, the underlying
>Core, XML, Events and Views DOMs (and the Stylesheets and CSS OM,
>though my understanding is that X3D does not use styling).
>
We have not done that yet.  Mostly a matter of time.  Justin has started 
a proposal for how this would work.   Don Brutzman has been preparing 
for this as well.  We are hampered a bit by the fact that we have an 
encoding that is not XML based.  So we are trying to please two 
different groups.  Style Sheets are definately not in the original VRML 
specification.  The problem becomes either specifying an analagous VRML 
syntax for each feature, or just having features in the XML encoding. 
 From an abstract specification viewpoint I dislike doing that. 
 Especially when we are trying to sync so many architectural/encoding 
users.  We have to keep a common view between scripting access(DOM and 
non-DOM access like Java bindings), XML and non-XML file 
formats(original UTF8 and stream binary).  So we will support style 
sheets but its been a hard road getting there.

>
>G> That said, I hope that all XML languages will interoperate at some
>G> level with a standard DOM.
>
>Clearly, if by standard you mean the Dom Level 2 stuff. This is
>generally the ,model that is assumed for the future - a large, single,
>multi-namespace tree. (For SVG we generalized further to a collection
>of such trees connected by XLinks to make a DAG, but that is by the
>by).
>
yes, Dom level 2 or maybe 3 in the near future.  The multi-namespace 
tree environment is the one we are really trying to validate right now. 
 I really want to integrate with at least one if not multiple XML spaces 
before we ship our standard.  I think SVG is the right one to bite off 
first.  We have a pretty common vocabulary and adding a nice 2D 
rendering engine to 3D simulations is a commond request of our 
users(either as a layer above the 3D space or as an internal texture to 
an object).  

>
>G> I've seen references to conformance issues. Are you stating that
>G> someone cannot build and modify an SVG document via the DOM but
>G> must use SVG DOM.
>
>That has (erroneously) been suggested in this thread, but not by
>myself or by Batik developers. It is absolutely not the case.
>
>Architecturally, it is imperative that access (both read and write)
>via the XML DOM be supported, and that additional methods and
>additional rendering layers have defined behavior in face of this
>manipulation. Which the SVG 1.0 specification does.
>
>G> Or is it just faster, more feature rich to use the SVG DOM?
>
>The latter. Certainly more feature rich, some information (such as the
>transitory, animated value of a property) is only available through
>this DOM. But it very definitely is an addition to, not a replacement
>for,the DOM 2 features and the Conformance section of the SVG 1.0
>specification is very clear about that.
>
This brings me back to the questions Justin was having.  We had hoped we 
could parse a multi-namespace document and just pass the SVG elements 
onto an SVG renderer.  I'm guessing what we are facing is the difference 
between future desires and current functionality.  Right now it seems 
very heavyweight for us to use Batik to render SVG content.  I have not 
dug into the actual Batik codebase yet, so I'm only going by Justin's 
report of the interfaces.  What I really want to avoid is having several 
copies of the parsed document around in memory.  Hence why we wanted to 
hand Batik a stock standard DOM and have it render the content.  We 
already have alot of our own URL resolution and caching architecture, so 
we'd like to avoid having Batik do these functions as well.  Same would 
go from the other side, ie an SVG document utilizing X3D to render some 
3D.  You should be able to hand us a document fragment and expect us to 
render that, without having to use our custom DOM layer.  An ideally we 
would only use the resources like caches and threads that are absolutely 
necessary.  In the static case, ie you ask use to render a scene once, 
then we should just render the scene and release all resources.

My hope is that Siggraph this year, which is July 21-26, we can show a 
demo which includes both X3D and SVG content running together.  Likely 
this would require a fair bit of coordination between our groups.  One 
question would be whether anyone in this group is planning to attend 
Siggraph?  Another would be whether this timeframe would work from a 
timing perspective of the batik team.  Ie, if we agreed to help program 
some of the changes we think are needed in Batik(of course we could be 
wrong that they are needed), would this be a good time?  We've been 
releasing major releases of Xj3D about every 4 months and plan the next 
one for Siggraph.  Obviously I'm not familiar with the current timing of 
Batik releases nor when you might be able to release another version. 
 But as a general question for this group, does this fit into your 
concepts for where Batik is going?

-- 
Alan Hudson
President: Yumetech, Inc.                      http://www.yumetech.com/
Web3D Open Source Chair        http://www.web3d.org/TaskGroups/source/




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re[2]: GVTBuilder error with custom DOMs

[Chris Lilley <ch...@w3.org>]

On Sunday, 17 March, 2002, 18:27:18, Giles wrote:

G> A brief introduction.  I'm Alan Hudson, the other lead on the Xj3D 
G> project, and typically the more politc member :)  I'm sure you've all 
G> meet Justin Couch by now.

Hi, glad to meet you.

A similarly brief introduction - I am Chris Lilley, member of the W3C
Technical Architecture Group, the XML and Hypertext Coordination
Groups, Graphics Activity Lead, and chair of the SVG 1.0 and SVG 2.0
working groups. I have also previously been chair of the CSS WG,
member of the HTML, WebFont, and XSL WGs and a co-author of the PNG
specification.

Before W3C I was at the Computer Graphics Unit at the University of
Manchester (for those with long memories of VRML trivia who recall
MSDL).

G> In regards to W3C, we had a good presentation of SVG and chat with Ivan 
G> Herman(not Evan Ireland)

It was close enough that I could guess, since I was aware that Ivan
was going to that event. There has also been contact in the past
between Web3D and both Max Froumentin (MathML and XSL WGs, previously
from the Computer Graphics lab at the University of Bath) and myself.

G> from W3C at our last web3d symposium.  His view
G> was that the issues that SVG and X3D face are very similar.  The 
G> requirements of rendering a real-time scenegraph are hard and they are 
G> pushing the XML document model pretty far.

I would agree with this assessment. Comparing what a modern SVG
implementation does, and what a legacy HTML browser does, is
enlightening to say the least. There were many holes and gaps where
specs left things unsaid, or assumed a batch transformation model, or
had simply never considered interaction, or were focused exclusively
on documenting short term existing implementation of legacy browsers
rather than looking at a wider architectural model. So for SVG 1.0,
where we were expecting de-novo, interoperable implementations right
from last call on our spec, there were a lot of challenges. We ended
up doing a great deal of liaison work and documenting a bunch of those
holes.

G> I found myself constantly
G> shaking my head in agreement as he described the challenges SVG faced 
G> and the solutions proposed.  I'm definately interested in the ins and 
G> outs of the SVG DOM specification.  We have similar scripting 
G> requirements which a standard DOM implementation will not handle.

The correct solution seems to be to layer the additional methods and
objects on top of, rather than as a replacement for, the underlying
Core, XML, Events and Views DOMs (and the Stylesheets and CSS OM,
though my understanding is that X3D does not use styling).

G> That said, I hope that all XML languages will interoperate at some
G> level with a standard DOM.

Clearly, if by standard you mean the Dom Level 2 stuff. This is
generally the ,model that is assumed for the future - a large, single,
multi-namespace tree. (For SVG we generalized further to a collection
of such trees connected by XLinks to make a DAG, but that is by the
by).

G> One of the reasons we need our own layer above DOM is for effeciency. 
G>  Passing string representations of field values is unreasonable for some 
G> of our datatypes.

Yes, I know. Its unfortunate that short-term legacy issues have left
us with a DOM that is not really object oriented and that is primarily
used with a language that is not really object oriented.

G>  An example would be a coordinate set for a human. 
G>  Its not unusual for X3D programs to animate every vertex each frame for 
G> an animated human.  If we had to represent this data as a string and 
G> then parse it each frame well, there goes real-time performance.

Absolutely.

G>  So we
G> have extra methods which allow you to represent datatypes in there more 
G> natural form(like float arrays).  But, we do allow access to these 
G> fields with their string counterparts.  So we can hand a standard DOM to 
G> someone and they can access the fields.   It may not be the most 
G> effecient, but it would work.

But the point is that you can

a) store the stuff in the more efficient array form
b) generate the string form on demand and throw it away afterwards
c) provide a more efficient DOM object that deals with arrays
directly, that is conceptually layered on top of the XML DOM
d) give it methods that do sensible matrix manipulations like
inversion and multiplication
e) suggest that using these methods is more efficient
f) provide a feature string so users can test for the availability of
these methods and conditionally use them, falling back to the DOM
level 2 methods if need be.

and the only catch is the XML requirement about preserving all the
spaces, line feeds and assorted garbage when you recreate the string,
which is a problem.

G>  Our standard example is someone might use 
G> this interface to turn on a lightbulb, but not to animate a human.  Is 
G> this the type of reason you needed a layer above the DOM?

Yes.

G> I've seen references to conformance issues. Are you stating that
G> someone cannot build and modify an SVG document via the DOM but
G> must use SVG DOM.

That has (erroneously) been suggested in this thread, but not by
myself or by Batik developers. It is absolutely not the case.

Architecturally, it is imperative that access (both read and write)
via the XML DOM be supported, and that additional methods and
additional rendering layers have defined behavior in face of this
manipulation. Which the SVG 1.0 specification does.

G> Or is it just faster, more feature rich to use the SVG DOM?

The latter. Certainly more feature rich, some information (such as the
transitory, animated value of a property) is only available through
this DOM. But it very definitely is an addition to, not a replacement
for,the DOM 2 features and the Conformance section of the SVG 1.0
specification is very clear about that.



-- 
 Chris                            mailto:chris@w3.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Giles <gi...@oz.net>]

Justin Couch wrote:

>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.
>>
>
>Persistent theme since at least mid last year. I was in one halway 
>meeting at Siggraph last year that involved 7 or 8 people, I don't 
>remember names now. Since then, the Web3d people that also go to the W3C 
>meetings have consistently reported this. The main two that I know from 
>the web3d side are Don Brutzman and Joe Williams. In addition, my 
>business partner was at the Web3d conference in late feb and had a very 
>long conversation with someone. IIRC it was Evan Ireland, but I'll have 
>to check on that.
>
A brief introduction.  I'm Alan Hudson, the other lead on the Xj3D 
project, and typically the more politc member :)  I'm sure you've all 
meet Justin Couch by now.

In regards to W3C, we had a good presentation of SVG and chat with Ivan 
Herman(not Evan Ireland) from W3C at our last web3d symposium.  His view 
was that the issues that SVG and X3D face are very similar.  The 
requirements of rendering a real-time scenegraph are hard and they are 
pushing the XML document model pretty far.  I found myself constantly 
shaking my head in agreement as he described the challenges SVG faced 
and the solutions proposed.  I'm definately interested in the ins and 
outs of the SVG DOM specification.  We have similar scripting 
requirements which a standard DOM implementation will not handle.  That 
said, I hope that all XML languages will interoperate at some level with 
a standard DOM.  

One of the reasons we need our own layer above DOM is for effeciency. 
 Passing string representations of field values is unreasonable for some 
of our datatypes.  An example would be a coordinate set for a human. 
 Its not unusual for X3D programs to animate every vertex each frame for 
an animated human.  If we had to represent this data as a string and 
then parse it each frame well, there goes real-time performance.  So we 
have extra methods which allow you to represent datatypes in there more 
natural form(like float arrays).  But, we do allow access to these 
fields with their string counterparts.  So we can hand a standard DOM to 
someone and they can access the fields.   It may not be the most 
effecient, but it would work.  Our standard example is someone might use 
this interface to turn on a lightbulb, but not to animate a human.  Is 
this the type of reason you needed a layer above the DOM?  I've seen 
references to conformance issues.  Are you stating that someone cannot 
build and modify an SVG document via the DOM but must use SVG DOM.  Or 
is it just faster, more feature rich to use the SVG DOM?


-- 
Alan Hudson
President: Yumetech, Inc.                      http://www.yumetech.com/
Web3D Open Source Chair        http://www.web3d.org/TaskGroups/source/




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

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.

Persistent theme since at least mid last year. I was in one halway 
meeting at Siggraph last year that involved 7 or 8 people, I don't 
remember names now. Since then, the Web3d people that also go to the W3C 
meetings have consistently reported this. The main two that I know from 
the web3d side are Don Brutzman and Joe Williams. In addition, my 
business partner was at the Web3d conference in late feb and had a very 
long conversation with someone. IIRC it was Evan Ireland, but I'll have 
to check on that.

> 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?

Pretty much. If you boil it down, there really isn't much different 
between X3D and SVG. There is a scenegraph of transformations, of 
geometry objects and material information about that geometry and of 
user input sensors. In addition there is also a scripting system and a 
runtime system - don't get these confused they are not one and the same 
thing. SVG happens to use an external spec for defining runtime 
semantics (SMIL) where X3D includes it as part of the core 
specification. It still does the same sort of thing though - makes 
dynamic changes to the properties defined in the original text-based 
file format. X3D scripting is a bit more explicit than SVG, but in 
rough, hand-waving terms, they are the same.

> 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).

In the way we do it with X3D, there is the external world view - the DOM 
, then there are the modifiers and externally defined content (we have a 
system for templating new "element" types called PROTO/EXTERNPROTO) and 
then there is the rendering engine. The rendering engine maintains its 
own state information. How much information is communicated to "the 
outside world" is dependent on the user of that information.

So we sort of do the second option - we have an DOM and an internal 
structure. To us, CSS is just another external input to the system, 
another structure that the core rendering engine uses during the 
rendering cycle. It looks for changes in the CSS and applies that during 
the next cycle, just like any other change that would come from the DOM. 
For example, we have both DOM and EAI access to the internal scenegraph. 
  EAI is a high-level Java API that has nothing to do with XML. If you 
count VRML97-defined APIs, we have four different APIs all wanting to 
access and modify the runtime structure - potentially simultaneously. 
That's why I say that to us CSS is just another API view into the core.

If we now sit down and compare our spec/system to the Batik core, you 
will notice that Batik is already 50% of the way there. GVT is the 
rendering core, SVG DOM is the external API and CSS is another external 
API, that may or may not be part of the DOM (when described as XML 
Processing Instructions rather than as a LINK). After parsing the CSS, 
it is just another, separate, input to the rendering engine. The core 
listens to events in the external APIs and makes the appropriate changes 
to the visual output. In this way, the DOM has its view, the CSS has its 
own, just as required in an earlier email. To boot, there's a hell of a 
lot less management code needed too.

For SVG, SMIL is just another part of the rendering engine too. It is 
identical to our event model, in that it is responsible for 
synchronizing multiple different content streams over a period of time. 
A SMIL instruction that says "start now" to the SVG is no different to 
an external user interaction telling the system the same thing through a 
UI component. The basic action is "start the system clock now/stop the 
system clock now". How that instruction is initiated is inconsequential 
and the rendering engine must treat it as such. At no time should the 
rendering engine need to know that the start command came from a SMIL 
document, from a mouse click on a menu item or a keyboard accelarator 
keystroke. Start, stop, that's all you need to care about.

> 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?

It depends on how the events are created and how the original source was 
generated. If the DOM comes from some external source, we just do the 
conversions into our internal scenegraph. Next, we look other features. 
Does the DOM have Events capability? If yes, we set up mappings from the 
DOM to our scene graph - we attach DOM EventListeners to the fragment we 
are working from and pass the information through to the render core 
when we see them. Right now, for the externally generated DOM, we don't 
pass events back out that change within the scenegraph internals. 
There's a bunch of reasons why, mainly inconsequential, so I'll footnote 
those at the end of the email.

When the DOM is generated by us, we still take the separated stand, but 
the DOM is now delivered all of the events. We take a bunch of 
optimisations about when and how events are delivered. We mainly operate 
in a stand-off mode. Our DOM works out whether a listener has been 
registered on a particular DOM node. If there is no listener in the tree 
looking for that event, we never deliver the value to the DOM, hence 
avoiding the huge overheads of the DOM event cascade/bubble 
requirements. In addition, our notification is purely "this has 
changed". There is no value involved. The DOM maintains a dirty flag on 
the field and then only updates the value when someone explicitly asks 
for it. We do this because a lot of the time, our events consist of one 
of two things - TimeSensor events and coordinate changes. For example, 
animating a typical humanoid character involves a single set of 
coordinate changes, where there is 1000+ 3-space coordinates as an 
attribute of a single element (if you throw in texture information, 
you'd triple that number at least). Turning that into an attribute 
string every frame would be a killer for performance.


Now, on to user interface events - Again we act in a two-way mode. We 
look for MouseEvent on the DOM and use that to drive objects and 
changes. In X3D, there is really only one node type that would respond 
to that - Anchor. We have touch and planesensors, but the way the spec 
is worded, basically implies that the events must originate from 
"inside" the scene graph.

In addition to the DOM model, we also have to deal with events generated 
from within the rendering engine. We don't really work with user input 
events on a generic architecture. The reason is that the various 
rendering APIs all define how they send input events to user-land code. 
For example, Java3D would send us AWT events through its behaviour 
system. J3D captures those events by itself, from its rendering surface, 
and will deliver those (potentially) in parallel with whatever the 
external UI might deliver through the DOM interface. However there are 
many other ways of getting user input events into the system. Again, 
using J3D behaviours, input can come from custom input devices which 
come through the behaviours system. In this case, we process the event 
through the rendering engine, make whatever calculations we need to do 
and then deliver the results to the externals of the scene graph.

This process probably sounds a bit odd, so probably needs more 
explaining. Within X3D, we don't deal with user input directly. There is 
no such equivalent to "onClick" attributes. Instead, we have nodes that 
are termed sensors. These are effectively the post-processed output of 
the user input. So, to listen to, and then act on, a click we have a 
TouchSensor node. This does the translation and says "the click happened 
here in 3D space, on these texture coordinates, on this geometry". 
(there are also equivalents of mouse over and mouse up/down). You then 
connect the output of this sensor to a script or another node, using an 
explicit model called ROUTEs. So, for us, having a mouse event come down 
through the DOM would be a very rare event, as it is mostly driven from 
internally detected sources.

> Is that 100 fps with only software, or does that include hardware acceleration?

Hardware accel for the lowest-level rendering. Everything above that is 
userland code. Event model, timing, scripting. At least for us, the 
performance bottleneck is the rendering API. We take advantage of 
multi-cpu machines by keeping the event model and rendering loops in 
separate threads. Only on the most complex of worlds have we noticed the 
  rendering loop waiting for the event loop to finish. On average user 
content, the render is the slow item.

In comparison to the SVG world, there shouldn't be any difference 
really. Most of the lowest-level stuff is still in hardware, or at least 
  down in the operating system-specific APIs (at least from JDK 1.3 
onwards, 1.2 was doing pure-java software rasterisers). If you started 
using VolatileImage as the output source, even most of the high-level 
operations like image transformation and clipping would be done in 
hardware on the video card. Given equivalent complexity of content, I 
would expect that SVG would end up with more software renderer usage 
than Xj3D. (However, we could, nominally, implement SVG with an OpenGL 
API and so have H/w accel for almost all operations).

> 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.

Why do you require sync control? Why can't you just be a good servent of 
the containing application and only update your output when it perceives 
it is a good time?


> 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.

Exactly, and currently Batik seems to be brushing this off as something 
that it is not willing to cater for. In doing so it is limiting its 
usefulness as a toolkit.

> 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.

Can you give a reason why? Surely you want your toolkit to be useful as 
widely as possible. If not, I'm wasting my time here and should go find 
another toolkit or write my own.

>>>   - 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.

Can you tell me why it doesn't address it? The statement is "SVG 
requires the core DOM + SVG extension". My response is that SVG requires 
it, but the implementation does not. The specification says "if you want 
to interact with SVG through a set of custom APIs that is specific to 
this content, use this set of extensions to DOM". I can quite happily, 
and perfectly spec compliantly, access and modify the SVG content 
through the DOM Core APIs.

If you read Appendix B, nowhere does it state that support for SVG DOM 
is required for an implementation of an SVG renderer. If you read the 
intro, it says " The SVG DOM is builds upon and is compatible with the 
Document Object Model (DOM) Level 2 Specification". B.6.2 quite 
concisely states that the DOM does not need to support the full DOM2 CSS 
implementation. Nowhere does it say "the only way to interact with SVG 
content is through the SVG DOM API".  The introduction in 1.1 say 
"Sophisticated applications of SVG are possible by use of a supplemental 
scripting language" Note the word "supplemental", which means "optional".

> I would love to hear how you plan to calculate the result of a
> bounding box request without a rendering engine.

Quite simple. The rendering engine does rendering. The bounding box 
calculation is not a function of rendering. It is a pre/post processing 
step.

Sometimes it may be more efficient to calculate the bounding box during 
the rendering process, but the rendering process is not *required* to 
calculate the bounding box. I could quite easily in userland code, 
traverse the DOM scenegraph and calculate the bounding box by hand. Or, 
I could create a null renderer, which does no output rendering, but 
responds to scripting and animations, and it could still calculate 
bounding boxes. There are thousands of webpages out there that can help 
you implement various bounding box calculation algorithms. None of them 
ever consider rendering.

> 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.

No. They are as intimate as the source materail allows. See the section 
above. If intimacy is permitted, make use of it. If given the cold 
shoulder, then live with it and get on with the rendering.

> 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.

Any application, at any one time will not be conformant. The transcoder 
API is not conformant using your rules because it generates a one-time 
image and doesn't take into account user input or scripting. Inlined 
content is no different. It is just part of a bigger structure. You can 
still be entirely conformant, but also working in unison with other 
players on the same page.

You also have to consider that conformance comes on many levels. You can 
be conformant to the static structure, and not support runtime 
information. You can also be conformant to various levels of runtime 
handling - see the profiling work that is going on with SVG 1.1. X3D is 
already a couple of steps ahead of you in that department. The minimal 
profile for a mobile phone is no different to the "no runtime" system 
too (in very general hand-waving terms).

Back to your statement about being non-conformant. If you read the 
Rendering Model of the spec (section 3), nowhere does it state that the 
implementation must control synchronisation of the user input events or 
anything. If you read G.6 or G.7 on Conforming Interpreters, nowhere 
does it say that the implementation must maintain control over its own 
rendering state. All it says is that the output must be correct. How you 
drive the internals of the animation engine to achieve that correctness 
is not specified.  In contrast, it does talk about the SVG being used as 
a document fragment within a larger document.

> That doesn't sound too hard. Just do a deep clone of the SVG subtree,

But that's what I explicitly trying to avoid! I don't want to clone the 
SVG tree. That's yet another piece of my memory you are consuming for 
your own greediness. I want you to use my DOM, and my DOM only. How rude 
of you to expect that we all feel like tossing all this extra memory in 
your directions when we already have a perfectly good copy floating 
around in memory already. My end users will be interacting through my 
DOM, so now I need to propogate not one, but two separte event 
cascades/bubbles everytime something changes. How badly with that stuff 
performance!

[1] Footnote on stuff about why we don't pass events out sometimes. The
Xj3D implementation of XML bindings is still lagging behind the core 
rendering API. This is because the XML DTD has been a somewhat moving 
target. There are some concepts in VRML that are close to impossible to 
express cleanly in XML and so there's been a lot of tossing and turning. 
Because some of these issues are core to the way the XML interacts with 
the rendering engine, we've let that part of the codebase lie dormant 
for a while. In the meantime, we've concentrated on getting the 
rendering engine and eventmodel handling correct. Once the XML side 
settles down, it shouldn't been too hard to then catch up. Effectively, 
anything XML has been put on the backburner, hence we haven't gotten 
around to work with sending internal rendering events back out to the 
DOM when the DOM is user supplied.

--
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

Re[2]: GVTBuilder error with custom DOMs

[Chris Lilley <ch...@w3.org>]

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:chris@w3.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

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

Re: GVTBuilder error with custom DOMs

[Thomas E Deweese <th...@kodak.com>]

>>>>> "JC" == Justin Couch <ju...@vlc.com.au> writes:

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> 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
JC> are is just <rect> here, <line> there and a bunch of css
JC> stuff. Admittedly X3D doesn't have CSS, but a CSS document is no
JC> different to an image, video, audio file, or in our case -
JC> external prototype files. What you do with that DOM is how you get
JC> to the next part.

    This shows a serious lack of knowledge of CSS. CSS effects
everything in SVG. Lets take a look a simple piece of CSS SVG:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="450" height="500" viewBox="0 0 450 500" xml:space="preserve"
     xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink">

     <style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
     <rect id="rect" class="fud" fill="blue" style="fill:green" 
           x="10" y="10" width="100" height="100" />
</svg>

    Can you guess what color the rect is in the following example? 
        The answer is 'green', 

    If you remove the style="fill:green" can you guess what color it is?  
        The answer is 'red'.

    Finally if you change the class or remove the style sheet the
object reverts to blue (what the xml attribute told you all along).

    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.

    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).
There are other things in SVG which are even worse.  Let's take a look
at the use element:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="450" height="500" viewBox="0 0 450 500" xml:space="preserve"
     xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink"
     fill="green">
     <style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
     <rect id="rect" x="10" y="10" width="100" height="100" />
     <use x="240" xlink:href="#rect" fill="orange" />
     <use x="120" xlink:href="#rect" style="fill:purple" />
     <use y="120" xlink:href="#rect" class="fud" />
</svg>

     The original rect inherits it's fill property from the SVG
element. The others inherit the fill property in various ways from the
use that references them.  This get's even more complex when the
referenced element is from another document, because then it must
respond to CSS selectors from it's own document, but inherit CSS
properties from it's referencing use element (not it's parent in the
referenced document).

     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.

---

     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, but as with the DOM/CSS issue you took a peek
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?).  In
the future you might try asking questions before forming opinions you
might be wrong less often.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

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

Re: GVTBuilder error with custom DOMs

[Vincent Hardy <vi...@sun.com>]

Justin,

I'll also respond to your email on the java3d-interest mailing list
and cc the batik-users list.

In the meanwhile, let me explain why Batik does not work
with a generic DOM tree and why it could not, even if it wanted to.

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. 

Concrete examples:

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

   - You cannot have a generic SVG DOM implementation because it
     requires a rendering engine. 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). The rendering engine is
implementation
     specific.

There are other examples, such as the implementation of CSS styling or
the implementation of the SVG structure (e.g., the <use> element).
Simply put: Batik exposes the DOM API as it is supposed to but can
only work with it own DOM implementation.

As to accepting a org.w3c.dom.Document in the GVTBuilder interface,
you have a point that we should document the restriction. We are 
accepting an org.w3c.dom.Document object for historical reasons and
I agree it is misleading.

Note that there is a utility to convert any DOM tree to our
implementation:

org.apache.batik.dom.util.DOMUtilities.deepCloneDocument()

Regards,
Vincent Hardy

This said, the 
Justin Couch wrote:
> 
> Either that, or state up front in the documentation that the generator
> of the document must support XYZ features for it to be usable with Batik.
> 

Yes, this is missing from the documentation, for historical reasons.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

Stephane Hillion wrote:
> And what about asking a Java and DOM training to your management??

Ok, assuming you don't know my background: I've been doing XML since 
sometime in 1997 and Java since early 1996. I wrote and lead the various 
working groups adding Java and the event model to the ISO VRML97 spec 
and authored the VRML97 External Authoring Interface spec that is Part 2 
of the VRML97 specification (it's just going through ISO FDIS voting 
now). I've been designing applications using XML since way back in the 
old ProjectX days. Never written a parser, by I've implemented my own 
DOM Level 2 builder, complete with events and views extensions. In 
addition, I give presentations on XML and DOM at various conferences 
too. My last presentation on DOM was at XML Asia-Pacific last November 
where I gave a tutorial on how application builders can intergrate and 
make use of DOM in their applications, up to, and including realtime 
systems and the DOM event model. Throw in authoring or contributing to 
10 books on Java and VR and I feel I hardly need Java and/or DOM 
training :)

-- 
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

RE: GVTBuilder error with custom DOMs

[Stephane Hillion <sh...@ilog.fr>]

And what about asking a Java and DOM training to your management??

> -----Original Message-----
> From: Justin Couch [mailto:justin@vlc.com.au]
> Sent: Thursday, March 14, 2002 12:57 AM
> To: Batik Users
> Subject: Re: GVTBuilder error with custom DOMs
> 
> 
> Just a followup to my earlier post. Decided to try out what the standard 
> KDK parsers give you as most users would be likely to use That.  No joy 
> there either. Guaranteed crash of GraphicsNode. This is kind of critical 
> to get fixed or documented. :(
> 
> -- 
> 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
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

Re: GVTBuilder error with custom DOMs

[Justin Couch <ju...@vlc.com.au>]

Just a followup to my earlier post. Decided to try out what the standard 
KDK parsers give you as most users would be likely to use That.  No joy 
there either. Guaranteed crash of GraphicsNode. This is kind of critical 
to get fixed or documented. :(

-- 
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