Hi Michael,
"Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on
10/03/2008 02:53:06 PM:
> > parl_to_parl takes two double[] src and dst as arguments. The
> > method maps one parallelogram to another, but
> > why does each double[] have 6 points? What is being passed in
> > here, a transform or a parallelogram? The rest of
> > the code makes sense.
>
> I might've answered my own question here by looking around for
> examples of the "three point" method. I forgot that each point has
> two coordinates. I believe that the double[] of src (and dst) are:
>
> { x1, y1, x2, y2, x3, y3 }
Correct.
> which is mapped into an AffineTransform (at) as such:
>
> (x2 - x1) (y2 - y1) (x3 - x1)
> (y3 - y1) (x1 ) (y1 )
> 0 0 1
This isn't a proper representation of their matrix.
They store it as:
sx, shy
shx, sy
tx , ty
So it's:
(x2 - x1) (y2 - y1) 0
(x3 - x1) (y3 - y1) 0
(x1 ) (y1 ) 1
Now if you input the points (0,0), (1,0), (0,1)
[the corners of a unit box] you get:
(x1, y1), ((x2-x1)+x1, (y2-y1)+y1), ((x3-x1)+x1, ((y3-y1)+y1))
-> (x1, y1), (x2, y2), (x3, y3)
The corners of your parallelogram; so that matrix maps
the unit box to the parallogram.
> What happens next is that "at" is inverted,
Which gives you the matrix from the parallelogram to
the unit box.
> then multiplied by a similar transform derived from
> the set of dst points.
So you have a matrix that goes src -> unit box -> dst.
> Now you have your new transform (D*).
>
> I have no idea WHY this works, but I think I'm on the right track of
> HOW it works.
Hopefully you have some idea why it works now...
> From: Bishop, Michael W. CONTR J9C880
[mailto:[EMAIL PROTECTED]
> Sent: Fri 10/3/2008 1:31 PM
> To: [email protected]
> Subject: RE: Tracking changes to the rendering transform?
>
>
> Hi Thomas,
>
> I'm following you most of the way with the basic concept. There are
> a couple things I'm confused about:
>
> parl_to_parl takes two double[] src and dst as arguments. The
> method maps one parallelogram to another, but why does each double[]
> have 6 points? What is being passed in here, a transform or a
> parallelogram? The rest of the code makes sense.
>
> You also say the approach is to build a matrix that maps a unit
> square to the edges of a parallelogram. What is a unit square? A
> square that encompasses the parallelogram, much like a traditional
> bounding box? I guess I'm still fuzzy on the overall concept.
>
> Good point that what the receiving client is getting is an
> "absolute" representation. It's not really a delta, it represents
> the current state, replacing whatever was there before. I wasn't
> thinking about it that way. Your explanation makes sense in the
> equation, but getting D* (applying the 3pt method) is where I'm
> lost. My method handles scaling, but yours handles everything, if I
> could figure out how to use it given three points.
>
> I'd be interested to see how this works and think it'd be useful. I
> made it through Ordinary Differential Equations in school, so I'm
> happy to finally be putting Linear Algebra and Trig to use in my career.
>
> Michael
>
> ________________________________
>
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Fri 10/3/2008 10:54 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: Tracking changes to the rendering transform?
>
>
>
> Hi Michael,
>
> "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]>
> wrote on 10/03/2008 10:22:42 AM:
>
> > > Once the receiving client gets these three points, I'm not clear
> > on how to derive the transform from the three
> > > points. That's a math issue, not a Batik issue of course.
> >
> > OK, I've been thinking about this issue some. I think I have an
> > idea for translate/scale, but I'm not sure about other transform
values.
>
> The best example I could find with google was the affine class from
agg:
>
> https://svn.enthought.
> com/enthought/browser/trunk/src/lib/enthought/kiva/agg/agg-2.
> 4/src/agg_trans_affine.cpp?rev=7913
>
>
> It has parl_to_parl methods that map any parallelogram to another
> parallelogram.
>
> > Let's say the receiving client receives 3 points; A1 (upper-left),
> > A2 (upper-right), and A3 (lower-left).
> > The receiving client already has a JSVGCanvas with three points C1,
C2, C3.
>
> The important thing about the three point approach is that you
> honestly don't care what the destination canavas was showing, all
> you want to do is map those three points to the corners of the
> client's window (I would ignore aspect ratio issues to start with,
> but the basic idea would be to modify the target canvas coordinates
> to account for aspect ratio differences).
>
> > I'm thinking that a translation is derived to translate C1 to A1.
> > Now both of the upper-left corners match. Now for X scale, you
> > calculate the distance between C1 and C2 and A1 and A2 and apply the
> > right scale multiple For Y, it's C1 and C3 and A1 and A3.
>
> This is correct and will handle scaling but see the example
> code as it will handle any rotation/skew as well.
>
> > I don't think you scale around the center; you scale around the
> > origin (C1).
>
> Correct.
>
> > What I'm not clear on now is the (unlikely) case of other transforms
> > such as rotation, skew, and shear.
>
> These should all just drop out of the above approach, that is what
> is so nice about it.
>
> > Am I even on the right track for starting to handle these changes?
>
> Yes, I think so, but trying to figure out how to derive the
> affine to map any three src points to three dest points isn't
> trivial unless you have a really good understanding of affine
> transforms. At some point I may try and write something for
> the wiki that explains how that 3pt mapping code
> works as it illustrates some useful ways of thinking about
> affine transforms.
>
> The basic approach is to build a matrix that maps a
> unit square to the edges of any parallelogram. Then you
> can use inverse and multiply to map between parallelograms.
>
>
> > From: Bishop, Michael W. CONTR J9C880
[mailto:[EMAIL PROTECTED]
> > Sent: Thu 10/2/2008 11:04 AM
> > To: [email protected]
> > Subject: RE: Tracking changes to the rendering transform?
>
> > > You aren't done yet...
> >
> > This is where I start to get confused. I have to remove the
> > existing VIEWING transform to derive the RENDERING transform? So I
> > "remove" the VIEWING transform by doing the inverse, then apply that
> > inverse to the RENDERING transform to get the final value?
>
> Right it's useful to view it this way:
> D = Display transform, goes from Root SVG elements
> coordinate system to screen pixels.
> V = Viewing transform, the transform established by
> the viewBox and window size.
> R = Rendering transform, the transform created by
pan/zoom/rotate.
>
> V*R = D
>
> Using the 3pt method you will calculate a new D -> D'. So you
> want to calculate an R' such that:
> V*R' = D'
>
> The easiest way to do that is:
> inv(V)*V*R' = inv(V)*D'
> Which is the same as:
> R' = inv(V)*D'
>
>
>
> >
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Tue 9/30/2008 9:21 PM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: RE: Tracking changes to the rendering transform?
> >
> >
> >
> > Hi Michael,
> >
> > "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]>
> > wrote on 09/25/2008 01:13:47 PM:
> >
> > > "The one thing you need to consider is that the rendering
transform
> > > does interact with the viewing transform (From the viewbox). So in
> > > the case that the window that is viewing the document is a different
> > > size/aspect ratio then you may need a different rendering transform
> > > to get the same 'view'. "
> > >
> > > In a whiteboarding situation, the document is supposed to stay in
> > > sync between clients. Assuming that we are syncing changes to the
> > > viewBox attribute, does this satisfy the need to manage the
> > viewing transform?
> >
> > I don't think so...
> >
> > Since the rendering transform sits outside of the viewing transform
> > if one client has a window that is say 600 pixels wide and is paned
over
> > so that the left edge is in the middle of the screen their translate
> > would be 300. However if that is applied to a Window that is 1200
> > pixels wide the left edge would only be 1/4 of the way across.
> >
> > One way to view this problem is to communicate what points in
> > the root SVG element's coordinate system correspond to the corners
> > of the window. With that in mind it's worth noting that a general
> > affine transform can be specified by the remapping of three points
> > (e.g. top left, top right, and bottom left points that are visible
> > in the document). So you can easily calculate those points by
> > mapping the corners of the window to the root SVG element's coordinate
> > system (on change of the rendering transform). If you then send
> > those points to the other clients they can calculate the transform
> > that would map those same points to the corners of the new client's
> > window (probably with some adjustment for aspect ratio - which is
> > simple if you don't allow for non-uniform scaling). You aren't
> > done yet because that is the full transform and you need to remove
> > the existing viewing transform to know what the rendering transform
> > should be. Fortunately that is simply a matter of inverting the
> > viewing transform and multiplying/premultiplying that with the
> > 'full transform' to get the residual that should be set as the
> > rendering transform.
> >
> > I hope that this makes some sense to you.
> >
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Thu 9/25/2008 6:34 AM
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: RE: Tracking changes to the rendering transform?
> > >
> > >
> > >
> > >
> > > Hi Dan, Michael,
> > >
> > > "Dan Slater" <[EMAIL PROTECTED]> wrote on 09/23/2008 02:01:01
PM:
> > >
> > > > Extend the JSVGCanvas and override the setRenderingTransform
method.
> > > > For example:
> > >
> > > Yes, this is how I would track changes to the rendering
transform.
> > > We don't expose it through any of the Swing change API's.
> > >
> > > > public void setRenderingTransform(final AffineTransform
at) {
> > > > //System.out.println("JSVGCanvasX set rendering
> > transform...");
> > > > setRenderingTransform(at, true);
> > > > Point2D.Double pt2d = new Point2D.
> > > > Double(locationListener.getLastX(),locationListener.getLastY());
> > > > SVGSVGElement root =
this.getSVGDocument().getRootElement();
> > > > if (root != null) setUserPositionXY(pt2d, root);
> > > > }
> > >
> > > "Bishop, Michael" <[EMAIL PROTECTED]> wrote on
09/23/2008:
> > >
> > > >> I'm in a whiteboarding situation where I want to communicate my
> > > >> "view" to other users. If I pan/zoom/etc, I want to be able to
> > > >> notify the other users as to what I'm looking at. I'm talking
about
> > > >> view changes that do not modify the document.
> > > >
> > > >> I believe I can do this by tracking the render transform. Is
there a
> > > >> way to listen for changes to the render transform?
> > >
> > > See above...
> > >
> > > >> Is there anything else I have to think about tracking to achieve
> > > >> this goal? I know the "viewBox" attribute exists, but that's
> > > >> different; it's a modification to the document itself.
> > >
> > > The one thing you need to consider is that the rendering
transform
> > > does interact with the viewing transform (From the viewbox). So in
> > > the case that the window that is viewing the document is a different
> > > size/aspect ratio then you may need a different rendering transform
> > > to get the same 'view'.
> > >
> > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
[EMAIL PROTECTED]
> [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
