Miguel,
<snip/>
> >> Have you played with Jmol source code and built the example .java
> >> viewer application?
> >
> > No, not yet. I am somewhat shy about getting too close
> > to "someone else's" source code ;-) In particular, I *much*
> > prefer to stick to a solution that does *not* involve (incompatible)
> > changes to existing code. I also prefer *not* to make use of
> > knowledge that is not part of an official interface if I can help
> > it.
>
> I suppose I misspoke when I said "Jmol source code".
>
> There is a sample Java application that you can compile which loads Jmol
> into a simple window. It is called examples/Integration.java
>
> *If* you get to the point that you want/need to use your own Java
> application (or your own applet), then you can start building your app
> from there ... without touching the Jmol source code.
Ok, it's about time I have a closer look at what I have already
from the Jmol source distribution - instead of bugging you with
my questions, thank you very much.
<snip/>
> > (2) As to the blitting approach more generally: some of my pupils
> > are connected to the Net via relatively slow dialup-lines.
> > Since we also want good audio-links, blitting too many raster
> > images too often does not seem such a wonderful thing to do.
>
> Agreed. Moving images in appropriate across a WAN with dial-up users.
>
>
> > If, instead of blitting many images, I just distribute the essentials
> > of new viewing information (like scale, view direction, translation,
> > etc. which amounts to a few doubles at worst) after one of
> > the participants has finished(!) resizing, rotating, or moving a
> > shared 3D model, and if I "interpolate" between the recipient's
> > current model state and the new (stable) state received over the
> > Net, modifying the local 3D model in "slow motion" from current
> > state to new state, I can get away with *orders*of*magnitude*
> > fewer bytes transmitted in the process - and still have very nice,
> > intuitive behavior of the model: (almost) no transmission or image
> > update delays, no image stuttering, no bad image quality: but the
> > "real thing" for each and every participant...
> Correct.
>
>
> > I am well aware that the "market" for my admittedly more difficult
> > approach to synchronizing the display of molecular models may
> > go away in the near future: namely, as soon as transfer speed over the
> > Net improves by at least an order of magnitude for *all* of my pupils.
> > But I want to do a first-rate tutoring job right *now*: so here is my
> > problem, and hence my need for your educated guess
> > as regards the difficulty of what I am hoping to achieve with Jmol
> > (whether semi-independent Jmol applet, or completely embedded
> > Jmol "plugin" for my scripted presentation documents).
>
> I don't think it will be too hard to do.
Given your replies I am now optimistic about it as well, of course.
> I can provide you with calls which give you the state of the display.
> Through a combination of JmolStatusListener enhancements and additional
> methods to inquire about the state of the transformations.
>
> (A note regarding rotations and zooms. I think that it would be very
> difficult to calculate and send 'deltas' to the current x, y, and z
> rotations. Instead, we will send the entire rotation matrix every time.)
Oh, yes, yes. That's ok. I like it even better. It would be awful if,
given deltas only, the distributed models got out of step when the
overall system is slightly disturbed. Although I assume the
connections are reliable - but even then: my experience tells
me *not* to make such assumptions, if I do not *have* to.
Perhaps something like a "dirty bit" - as in virtual memory
management systems - might be useful and conceivably not too
difficult to handle, I imagine - though I am not sure that such tricks
are worth the effort. In fact I rather doubt it: keep it simple!
If some delta-making were required for transmission purposes, I
could do it myself just prior to sending things off. And the interpolation
affair is entirely the job of the remote copies themselves because they
know best what the current state of their own model happens to be
and what it means to interpolate from that state to the newly received
target state. It is important that the received target state information
be self-sufficient in the sense of *not* depending on what the actual
state at the receiving end happens to be: because of network delays,
the states at the various receiving ends might, in very rare cases, actually
be different! Such temporary inconsistencies must *not* be allowed to
*persist* indefinitely - as they might if interpration of new state
information received *depended* on old state information locally stored.
Although there is no need for perfect "distributed transaction handling",
there is surely a need for simple and robust re-synchronization behavior
overall.
The main point is to have access to state information and to
be able to force all other shared models to that *same* state. The
more complete *that* information, the more complete synchronization
of distributed models can be made to be. So, for my application, it
would not be particularly useful to get *more* status information than
what status can be forced externally on a given model. These two
aspects of the interface should be "nicely balanced".
I, for one thing, am not asking for continuous dragging events, for
example. (JavaView supplies such events: I have no use for them.)
In fact, I am quite happy to test for model changes just between
successive mouse-down and mouse-up events. There is (always
for my application) no need for *immediate* shipping-off of *every*
tiny bit of a change. Interpolation can make the behavior of remote
peers of the model natural enough, that much I know from what
I have done already for Java 3D models. (But "slow motion"
interpolation between old and new state *is* important because
a user's perception of 3D models *depends* on his or her being
able to visually *relate* old and new state by *watching* the
model "move" from old state to new state in this manner.)
> The more I think about this the more I am beginning to think that we
> should consider embedding this functionality into the base JmolApplet. I
> don't think it would add too much overhead, and it would allow others to
> use your distributed teaching method.
>
> Let's keep talking.
But I do not advocate adding seriously to your burden as a Jmol
developer. It is just that I believe that, for *my* special purposes,
it would be a good thing to have. I can live with a partial solution
and wait 'till you can spare the time...
Now I am *definitely* going to read that integration example...
Thank you for your answers,
Christian
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Jmol-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-users
