Re: [Fenfire-dev] PEG: Recursive vobscenes

[Benja Fallenstein]

Tuomas Lukka wrote:
> =============================================================
> PEG vobscene_recursion--tjl: 
> =============================================================
>
> :Author:   Tuomas J. Lukka
> :Last-Modified: $Date: 2003/08/06 16:27:43 $
> :Revision: $Revision: 1.7 $
> :Status:   Current
>
> Performance problems in FenPDF as well as running out 
> of coordinate systems show that we should soon make a big
> change I've been mulling over for some time: make vobscenes
> hierarchical.
>
> Changes
> =======
>
> The API changes are minor. 

Again, explain the *model* first. What does it mean that vob scenes are 
hierarchical?

I understand that it means that a vobscene can be placed into some other 
scene; so for example we could create a vobscene containing a vector 
graphic, and then place that vobscene (i.e., the graphic) into some 
other vobscene (e.g., onto a FenPDF canvas).

Does this mean that a vobscene acts simply like an image?

Clearly, at least we need to be able to see the child's coordinate 
systems as coordinate systems of the parent scene: We need to be able to 
use them as anchors for buoys, for example. -- How will this work? Will 
there, for every cs `i` in the child, be a corresponding cs `j` in the 
parent?

I presume that child vobscenes are placed into coordinate systems of 
their parent scenes.

Can a child vobscene be placed into more than one coordsys of the 
parent? How would this work?

Is the "root" coordsys of the child (if there is such a concept) 
identical with the parent scene's coordsys that the child scene was put 
into? Or is the child "root" cs treated as a *child* of the parent's cs 
that the child cs was put into? (Does it make a difference?)

>     /** Create a new VobScene that may be placed into a VobScene
>      * by the putChildVobScene call.
>      * @param reserveCS The number of initial coordinate systems in scene
>      *  to replace with coordinate systems of the surrounding scene.

What do you mean by this?

It's s/in scene/in the scene/, anyway.

> Placing Child VobScenes
> -----------------------
>
> Extend ``VobScene`` by
>
>     /** Place the given VobScene as a child.
>      * The given VobScene must not be modified after this call.

Don't say "must not be modified," say "exception X is thrown when there 
is an attempt to modify the child vob scene."

>      * @param child The child VobScene to place. Child vobscenes
>      *          need to be created especially, through
>      *          RenderingSurface.createChildVobScene

I don't see why ChildVobScene isn't its own class, providing type safety 
instead of "you should do it like this."

>      * @param key The key to use

How does the key work? What's it used for? I'm mystified as to why there 
would be a key passed at all.

>      public void putChildVobScene(VobScene child, Object key, int[] cs);

**What is ``int[] cs``?**

> The key shall be passed to VobMatcher in the normal way.

What is "the normal way?"

> VobScene methods 
> ----------------
>
> Finally, a method getting VobSceneVob coordinate systems, in VobScene::

What is ``VobSceneVob``?

>     public int subSceneCoordsys(int vobId, int nth);

Why are you re-baptizing "child vobscene" to "sub scene" now?

What the hell is ``vobId``? How do I get it?

> VobScene semantics
> ------------------
>
> So far, the only special CS has been coordinate system 0.
> From now on, coordinate system **1** shall be the "root" coordinate system,
> and **0** remains the "identity" coordinate system (representing
> an identity transformation).

You should say how cs 0 worked before.

> The unit box of CS 1 is set to screen size, while the unit box
> of CS 0 is (1,1).
>
> OpenGL implementation
> ---------------------
>
> In OpenGL, the recursion is implemented by a special coordinate system type
> and a special Vob. 

Who creates these? What kind of special vob?

> The special coordinate system type causes the Coorder to call a method

When?

> to get the child coorder through an interface given to it, giving itself
> as the parent parameter.

I don't understand this.

If you don't want to elaborate on this much, you should leave this 
section out completely; so far, it explains about nothing to me...

> Issues
> ======
>
> - Should we have a "VobSceneVob", i.e. a Vob that contains a different
>   VobScene or some other approach?

*Now* you explain what ``VobSceneVob`` is? Bit late...

>     RESOLVED: Something like that, but extended, since we want to export
>     several coordinate systems from the child vobscene to the parent,
>     in order to do anchors. This cannot be done by a normal Vob so we need to
>     really touch the VobScene itself.

Um, "something like that" isn't a very precise resolution...

>     This is also because of interpolation: placing the "VobSceneVob"
>     into the parent must have a key to allow interpolation *inside*
>     a VobSceneVob. Therefore, it cannot be called a Vob. (This feature
>     will be implemented only in the future)
>
>     In fact, it seems that we should support placing VobScenes directly.

In fact, it seems like the "Changes" section is already written like 
that. If this is considered an issue at all, *this* should be its 
resolution.

> - What should the efficiency demands be? Linear w.r.t. child size?

Efficiency demands *for which operations*?

Be precise: Say "w.r.t. number of vobs and coordinate systems in the 
child" (if you mean that, at least).

>     RESOLVED: Linear is not good enough! Consider a huge canvas that
>     has been generated and is placed into a viewport, and most of it is
>     culled away. One of the very reasons for this PEG is that we need
>     to have more speed in this case.
>
>     Therefore, the time should be linear w.r.t. the **rendered**
>     coordsystems of the child, but constant w.r.t. child size.

This sentence makes me even more curious about what operations you're 
talking about...

>     This makes
>     life a bit more difficult internally (can't just copy a list, have
>     to point to it) but should be well worth it e.g. for FenPDF.

Um, is this really about copying a list vs referencing it? If we can 
make life easier by just copying a list, I submit that's a really cheap 
operation, even though it is linear in time.

If we need to *look* at the list (e.g., if the child was placed at index 
``i``, add ``i`` to every coordinate system number in the list), now 
that's another story.

> - Are modifications to child vobscenes allowed?
>
>     RESOLVED: Using a vobscene after a child that was placed into it
>     has been altered in any way **except** coordinate system parameter
>     change gives undefined results for now. Possibly even crash.

Sounds weird. I thought you'd outlawed changing the child after it is 
placed; that sounds much more sensible than allowing the child to be 
changed, but then not allowing the parent to be used any more. (Huh?)

Besides, what you *should* do is throw an error, not "give undefined 
results, possibly even crash."

> - Do we need to define coordinate systems other than the root of the
>   child from the parent?

I don't understand the question.

> - How generally do we need to define the coordinate systems 
>   inside the child (the ones passed to the child as "parameters")?

Same here.

> - How do we place the child vobscene and choose the vobscenes? 

"Choose the vobscenes"?

>     RESOLVED: A special call in VobScene, since the child vobscene
>     needs a *key* from the parent coordinate system, to allow
>     interpolation (not implemented now).

?

> - Matching between different versions of a coordinate system?

What?

> - Is a normal VobScene usable as a child vobscene? Or do we need special
>   operations?
>
>     RESOLVED: No, it should not be usable. 
>     Too much overhead and difficulties. 

What kind of?

- Benja