[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Rotation, new view system
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Rotation, new view system
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Fri, 23 Feb 2001 17:09:17 +0200
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3A963AC5.1C259749@xxxxxx>; from b.fallenstein@xxxxxx on Fri, Feb 23, 2001 at 11:26:13AM +0100
- Mail-followup-to: Benjamin Fallenstein <b.fallenstein@xxxxxx>, zzdev@xxxxxxxxxx
- References: <20010222172054.B10331@xxxxxxxxxxxxxx> <3A963AC5.1C259749@xxxxxx>
On Fri, Feb 23, 2001 at 11:26:13AM +0100, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > While Benjamin was in Finland there was some talk about renewing the view system.
> > Specifically, views used as subviews of other views were discussed.
> I find that terminology confusing-- it sounds like the purpose is that
> one view is _always_ called by the same other view, thus being the
> other's "subview." I see that "subwindow" doesn't make too much sense,
> but something along these lines...
> I have been sick and mainly unable to work on the new view system. I
> know what the main problem is, though: the data structures. Basicly, the
> view system we worked out when I was in Finland is a directed network
> without loops, not a tree-- and I haven't found an efficient way to
> represent that in Java yet. I'm inclined to let the issue rest at the
> moment and write a quick-and-dirty slow-running powerless implementation
> using a mere tree that can be extended later.
Something else to chew on: for the demos we want to be able
to do things fast so one option is caching parts of the structure
(kind of like ZObs) in a cache and add observers to the structure
so that we can reduce the rendering into just images or OpenGL display
lists and splat them on the screen. This is because many views will
be based on large numbers of small, unchanging items...
> > There's now a great need for something like this, as with the paper
> > (see Documentation/Manuscripts/HyperRFC) we discovered that
> > rotating the connected parts that float, the view is much clearer
> > than without rotation.
> I don't think I understand. First, you mean 2D rotation, not 3D, right?
For now, yes.
> Second, what kind of rotation do you mean-- making them float in
> circles, but in the same orientation (the text is always straight up, as
> you expect it to be) or real ROTATION (i.e., the text itself is rotated
> around its center)? And, what would be the benefit of that?
Text itself. When there is lots of text, it helps you see what belongs
> I can find nothing related to rotation in HyperRFC/hyp.tex. Where
> exactly should I look?
You said in a later email that you did find it.
> > I think that the Java2D possibility for using rotation would be best
> > done at the level of individual subviews - that way, Java1.1 clients
> > that do not have rotation do not have to pay for it (i.e. having a
> > rotation variable for each VOb would be way too much of a price to pay).
> I don't understand. What do you need a "rotation variable" for? And what
> would you gain if you put it in the vobset ("subview") instead of the
> vobs? Or do you want some callback into the views, or what? I'm lost.
A variable in every vob = a LOT of memory waste.