fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] PEG: Recursive vobscenes


From: Tuomas Lukka
Subject: Re: [Fenfire-dev] PEG: Recursive vobscenes
Date: Sun, 14 Sep 2003 14:58:45 +0300
User-agent: Mutt/1.5.4i

On Sun, Sep 14, 2003 at 01:32:40PM +0300, Benja Fallenstein wrote:
> >Changes
> >=======
> >
> >The API changes are minor. 
> 
> Again, explain the *model* first. What does it mean that vob scenes are 
> hierarchical?

Thanks for reminding me. It seems to happen to me often that I think
about something really deeply, then it clicks and then I explain things
to everyone, expecting them to know all the same things.

Sorry.

Fixing the PEG now.

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

No. The Issues section has some things about this but expecting readers
to read it is not good. Fixing.

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

Yes. This is taken care of. Also, coordsyses would be able to go the other way
too.

> -- How will this work? Will 
> there, for every cs `i` in the child, be a corresponding cs `j` in the 
> parent?

There's a special method to create coordinate systems corresponding to
requested ones in the child.

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

It's given a list of coordinate systems. They then become the child's
n first coordinate systems (0, 1, ... n-1)

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

See Issues section. Or the Introduction section in the next version of the PEG.

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

ARRRGH. I had *no* idea before rereading how insanely unclear that was.
Fixed in next version of PEG.

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

We can't do that without putting the test everywhere, slowing our
most critical innermost loops.

Added as an issue.

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

Good idea.

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

To allow interpolation in the future.

> >     public void putChildVobScene(VobScene child, Object key, int[] cs);
> 
> **What is ``int[] cs``?**

Oops. Fixed in PEG.

> >The key shall be passed to VobMatcher in the normal way.
> 
> What is "the normal way?"

Fixed.

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

Graa, more remnants. Fixed.

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

Done

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

Implementation of _putChildVobScene.

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

Inside the C++ Coorder.

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

Left out.


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

Fixed.


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

Fixed

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

Fixed

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

No, copying isn't fast at the sizes we're looking at any more... And especially
we can get creative on the OpenGL side, creating the Coordinate system
objects when first placing the ChildVobScene. This is something that *has*
started to be too slow in FenPDF!

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

Like I said above, this is the innermost loop...

Hmm... of course, we could do it by allowing the child vobscenes be created
as a different class and only those placed.

That might make sense...

> >- Do we need to define coordinate systems other than the root of the
> >  child from the parent?
> 
> I don't understand the question.

Do the coordinate systems of the parent affect any other coordinate systems
except index 0 of the child?

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

Hmm... read the fixed version of the PEG and see if this is still a problem.

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

Typo. Coordsyses.

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

Graah!!! s/coordinate system/child vobscene/.

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

Defining the parameter coordinate systems, I think. Not absolutely sure.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]