[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] OrthoCoordsys???
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz] OrthoCoordsys??? |
Date: |
Fri, 23 Aug 2002 14:13:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 |
Tuomas Lukka wrote:
The *interface* doesn't say you have to do that... You can make a
RenderInfo
implementation that does exactly what you propose.
Ok. But again, I don't see why querying it from the coorder would be
less efficient.
No, but it's less interface changes. Changing interfaces when it's
not really necessary is bad.
The point is that a) the current interface is terribly twisted, and b)
we really should be able to get information about coordsys other than
our own when drawing: for example, a connection may want to clip by the
smallest common ancestor of its two coordinate systems, and as another
example, we frequently need to query information about different
coordsys during view building. Currently we can do this, and we do this,
by using Coorder.getRenderInfo(cs), which is neither efficient (creates
objects) nor clean.
Besides, what you said earlier is that you were worried about
performance, and wanted benchmarks, not that changing interfaces is bad.
Hmm... but might it not be more efficient to have a facade VobScene
so that you just put it normally into the vobscene?
More efficient to have an additional Java object? I want coordsys to be
cheap, so that you don't have to worry about creating one more.
Yes, but the facade vobscene doesn't need to really *be* a vobscene:
it can work just like your implementation: contain an int inside. The point
is that then you don't have to keep passing the int around everywhere.
Intuitively, I don't like the gotchas here: forgetting to set the int
inside back when a function you've called returns.
Umm, who says *YOU* should take care of that?
I'd think it would go so that you call VobScene.getSubVobscene()
which returns a new vobscene. If you care about efficiency, you release()
the subvobscene in the end so it can be used again, but that's not vital.
Ok.
I don't like it. When I create a coordsys, I get an int, not a vobscene.
When I place a vob, I use that int. When I call another function that
places a vob, I pass the int. When I call another function that places
coordinate systems, I'd need to call getSubVobscene(coordsys) and pass
that. Can I place vobs in that sub-vobscene? No, not without an
interface change, only coord systems, and then vobs in those coord
systems. It seems terribly inconsistent.
Then there's nothing that the user has to really care about.
*AND* the API remains the same as before, which would be nicer.
The old API simply didn't allow you to do the things the new API allows
you to do, so it seemed reasonable that CellContentViews are passed ints
while Views are only passed VobScenes. Now this is an inconsistency. We
change the API in any case (adding getSubVobscene in your proposal), and
one way makes it inconsistent, and another way makes it consistent. I
like the latter better.
Because there it doesn't help that you are already in one because you have
to know coordinates in both of them anyway.
Ok, so we'd need sorting in GL anyway, even if we place all the coordsys
in one vobscene at a time? If so, why don't we make it a recommendation
instead of a requirement to put all the coordsys at the same time?
Sorting?
If it's not sorting, what makes it slow?
So that OpenGL
gets the scaling right. I think that in some ways the current system is
too simplistic:
if I put a vob at (50,50) that is (100,100) in size, then how should the
coordinate
system inside it behave? My initial reaction is that it should be
selectable,
so that you can say "Oh, and inside, the point (50,50) is (0,0) and
(100,100) is (10,26)".
How would you accommodate that?
I think it *is* useful here to build on the thinking that has been done
already, so the mental model I started with was like putting PUI
components inside each other (which only translates). As for the next
step, what about finding out how Berlin does this? They *do* have the
same problem, after all.
Well, I've actually solved this problem once before for PP: there you have the
viewports to the larger papers. This is just about the same situation.
The solution was simply to have two coordinate systems for each viewport:
1) the coordinate system for the edges
2) the coordinate system that the vobs inside obey.
Please explain-- I don't understand at all. What are "edges"? This
doesn't seem to have anything to do with the discussion above.
The point is that it's unreasonable to bind both the clipping *and* the internal
coordinate system to the same coordinate system.
???
That's why I'm opposed
to your int system.
"int system"?
- Benja
- Re: [Gzz] OrthoCoordsys???, (continued)
- Re: [Gzz] OrthoCoordsys???, Benja Fallenstein, 2002/08/22
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/22
- Re: [Gzz] OrthoCoordsys???, Benja Fallenstein, 2002/08/22
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/22
- Re: [Gzz] OrthoCoordsys???, Benja Fallenstein, 2002/08/22
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, Benja Fallenstein, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, Benja Fallenstein, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/23
- Re: [Gzz] OrthoCoordsys???,
Benja Fallenstein <=
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, Tuomas Lukka, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, reverting, Benja Fallenstein, 2002/08/23
- Re: [Gzz] OrthoCoordsys???, reverting, Tuomas Lukka, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Tuomas Lukka, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Benja Fallenstein, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Tuomas Lukka, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Benja Fallenstein, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Tuomas Lukka, 2002/08/24
- Re: [Gzz] OrthoCoordsys???, reverting, Benja Fallenstein, 2002/08/24