OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix


in that case I like Benoit's approach best.
 
Thanks,
Dieter


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Dienstag, 10. Juni 2008 11:36
To: Weidenbrueck, Dieter; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix

Maybe I didn't answer Dieter's question:  "Or, in other words, any rotation or scale becomes a composed matrix right away of two translations and one rotation or scale.Therefore, I am unclear what translate, rotate etc on the WebCGMAppStructure should do?"

The choices seem to be:

1.) Current 2.1 design:  three WebCGMAppStructure method calls:  ((myObj.translate(-5,-10)).rotate(45)).translate(5,10)

2.) versus building a composite-matrix with a few utility method calls (per Benoit this morning) and a single WebCGMAppStructure method invocation:  myObj.setTransform(composite-matrix)

3.) Or else build the convenience methods (scale(), etc) with a reference point.  (Per Airat's original contribution.)

-Lofton.


At 09:15 AM 6/10/2008 -0600, Lofton Henderson wrote:
As I recall, we made the choice that the primitive operations we support in the DOM would be w.r.t. the Origin. 

So to rotate an object 45-deg about (5,10), one would have to invoke the DOM methods:  translate(-5,-10), then rotate(45), then translate(5,10).

The original proposal of Ulrich's team included variants for primitive operations w.r.t. any arbitrary reference point, but we decided (IIRC) to keep it simple.  If we were to  change and decide now to offer those variants in the DOM methods [e.g., rotate(deg, ref-pt, replace)], then the DOM implementation has to do the equivalent of the above operations in any case, of course.

-Lofton.

At 10:56 AM 6/10/2008 -0400, Weidenbrueck, Dieter wrote:
All,
 
I am not sure whether I am understanding the wrong thing here, so please forgive me.
 
A rotation always requires an origin, and so does any scale.
So if a grobject has a rotation angle, an origin would have to be specified, e.g. the center of the object. However, this is not what i would expect to be the solution. To rotate a line (e.g. to open a switch on a schematic) around one of its endpoints, you need to do the following:
 
Be x1, y1 the start point, and x2,y2 the end point of the line.
Then:
 
A rotation around the start point would require:
 
translate ( -x1,-y1)
rotate(angle)
translate (x1,y1)
 
Or, in other words, any rotation or scale becomes a composed matrix right away of two translations and one rotation or scale.
Therefore, I am unclear what translate, rotate etc on the WebCGMAppStructure should do?
 
Dieter


From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Dienstag, 10. Juni 2008 10:33
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix

I guess another alternative could be:
- keep translate, rotate, scale on the WebCGMAppStructure
- replace the matrix API with the setTransform()
- remove createWebCGMMatrix.
 
So users could call translate, rotate, scale for the basic operations. And if they want to go for more complex, they could do a getTransform() which returns a WebCGMMatrix; and then modify the values as desired before calling setTransform.
 
Benoit.


From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com]
Sent: Tuesday, June 10, 2008 10:20 AM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix

I suspect that most of the transforms will be simple translate, rotate or scale.  If I needed to do more complicated stuff I would probably do my calculations ahead of time (as much as possible) and the output would inlude the javascript to do the transforms.  So I guess my answer for 1,2 is either the attribute should be writeable or we need a method to set the matrix to the value I specify.
 
As far as removing scale, rotate and translate from WebCGMAppStructure I guess the only question I have is does this have an negative impact on performance because two (or more) methods are needed or is that faster than the overhead of allocating a new data structure behind the scenes?
 

--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656

 

From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Tuesday, June 10, 2008 5:58 AM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix
I wasn't proposing to remove getTransform() All I'm saying is that I do not believe many script writers will venture in that area. Regardless, here is the WebCGMMatrix proposal
interface WebCGMMatrix {
    attribute float a;
    attribute float b;
    attribute float c;
    attribute float d;
    attribute float e;
    attribute float f;
WebCGMMatrix multiply (in WebCGMMatrix m);
WebCGMMatrix inverse(); // raises exception
WebCGMMatrix translate( in float x, in float y );
WebCGMMatrix scale( in float sx, in float sy );
WebCGMMatrix rotate( in float angle, in float rx, in float ry );
};
I would then replace WebCGMAppStructure::translate(), rotate(), scale() and matrix() for a new API WebCGMAppStructure::setTransform ( in WebCGMMatrix, in WebCGMString replace );
getTransform() would return a WebCGMMatrix.
And we need a new API either on the Picture or Metafile interface ::createWebCGMMatrix (it returns a new WebCGMMatrix initialize to the identity matrix).
Questions:
1) Should attributes a..f be read only (i.e., the idea is to prevent the user from messing up matrix)?
2) Do we need other methods on the WebCGMMatrix interface?
3) WebCGMAppStructure methods, translate, scale, rotate and matrix are gone, what do people think of that?
Regards,
Benoit
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Monday, June 09, 2008 5:34 PM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] What to do with WebCGMMatrix
I tend to agree with Dieter, although I am not an experienced practitioner in DOM programming.

However, I also have a procedural/timing concern.  I'm thinking that this is not best timing to discuss removing getTransform() -- unless everyone were enthusiastically unanimous to do so -- as we are trying to prepare CD02 text.  (Recall that there are small windows for technical adjustment in the WG; and then the TC approves any substantive changes when the work comes back from the W3C.)

If we don't remove the getTransform() now, then we need to have a parameterization of the return value.  Which means either array matrix[6] or interface WebCGMMatrix.  (Rob has concerns about whether such return type as matrix[6] is supported by IE, regardless of whether it is valid in IDL and ECMAScript.)

Let's discuss further (on Wednesday, if not here).

-Lofton.

At 02:39 PM 6/9/2008 -0400, Weidenbrueck, Dieter wrote:
Benoit,
I think it is needed. If you request the current transform of an object you have no idea what it might be, and very easily it may be a complex matrix resulting from multiple transforms (in fact, this should be the default case for even a simple rotation).
So if you want to concatenate transforms (e.g. a rotation) and be able to restore the result before the concatenation, you can only use a matrix IMO.
Regards,
Dieter
From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Montag, 9. Juni 2008 13:58
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] What to do with WebCGMMatrix
Hi All,
I honestly don't know if we need WebCGMMatrix. The methods (translate, rotate, scale, matrix) may not the "prettiest" from a coding stand-point, but I think they get the job done.
Personally, I think very few users will use matrix() and getTransform(), so I don't know if it justifies a new WebCGMMatrix interface.
I think it makes more sense to add a WebCGMRect interface than a WebCGMMatrix interface.
Thoughts on this?
If many of you want WebCGMMatrix in, I can add it; but I get the impression I'm alone on this one.
Benoit.

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.1.0/1492 - Release Date: 6/9/2008 10:29 AM



No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 6/10/2008 7:22 AM

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 6/10/2008 7:22 AM


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]