[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fenfire-dev] PEG: Recursive vobscenes
From: |
Benja Fallenstein |
Subject: |
Re: [Fenfire-dev] PEG: Recursive vobscenes |
Date: |
Sun, 14 Sep 2003 13:32:40 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030908 Debian/1.4-4 |
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