From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Sat, 2 Jun 2012 20:02:45 +0200

To: public-fx@w3.org, www-svg@w3.org

Message-Id: <201206022002.46351.Dr.O.Hoffmann@gmx.de>

Date: Sat, 2 Jun 2012 20:02:45 +0200

To: public-fx@w3.org, www-svg@w3.org

Message-Id: <201206022002.46351.Dr.O.Hoffmann@gmx.de>

Dirk Schulze: ... > > > For the operation of addition of matrices M: 0:=scale(0,0) represents > > a neutral element M = M + 0 = 0 + M, but typically this is not very > > important for transformations in SVG or CSS. > > I added a first draft of the definition for the 'neutral element of > addition' to CSS Transforms [1]. The only problem that I see is with > 'matrix', 'matrix3d' and 'perspective'. According to the definition of SMIL > the values should be 0 (list of 0) as well. This would be a non-invertible > matrix for 'matrix' and 'matrix3d' This applies as well for scale(0,0), scale(0,y), scale(x,0) etc, therefore no really new problem. I got the impression from the previous discussion, that this quaternion approach could avoid the nasty problem of matrix inversion, but still the related section contains such nasty implications, which cause such problems. As long as this is not stabilised by avoiding inversions, such problems will remain - mainly with the funny effect of surprising discontinuities in animations for authors (maybe CSS using authors can work around this in some cases with a 'rotation' with infinitesimal radius and size around the '0', as long as nothing better is implemented/available, but this requires more manual computation of the timing (keytimes) by the author ;o) > and a undefined matrix for > 'perspective'. With the few tests (CSS+XHTML) I made related to perspective with viewers available for me, I could not see an effect anyway, this was even worse than for other 3D effects. But obviously looking at the matrix in 21 it represents, 0 would be indeed interesting ;o) On the other hand - currently it is not yet defined, how to apply such matrices at all to get a perspective view - maybe it is an approach to change this matrix and use a respectively modified formula ;o) As long as the behaviour is not defined, there is nothing to discuss or to implement for 3D transforms ;o) In doubt, indeed one has to define a specific rule once it is defined, how such 3D-matrices are applied. But looking on the matrices, implicating already some concept, my assumption is, one cannot avoid a problem here. Due to the graphs in 6.1. d="0" means, that the eye of the observer sticks into the canvas/object or vice versa - one cannot expect a meaningful behaviour for this. Because for the perspective property with similar meaning it is already mentioned, that the length must be positive, one just has to define what to do for a not positive value - automatically one gets the correct behaviour, if this appears in an animation, including the result of a by-animation of perspective - I think, it will apply for the property and the transform type. > The interpolation chapter for matrices does not allow > interpolation with non-invertible matrices [2]. Well, this is not nice. I think, Opera has implemented this for years already for matrix and I did some simulations with an animation of xlink:href of a use element with about 20 references a second, and of course, there is no visual problem at 0 - it happens only, what can be expected - everything is reduced to an (invisible) dot. It causes no problem to apply such matrices without animation to arbitrary content, therefore it can be expected, that an animation method is chosen, that does not introduce problems in areas, where are no problems. Fortunately we know already a method, that causes no such additional problem. This is described in SMIL. Of course, there can be others as well. And I think, to apply this CSS specific decompostion method to a SMIL animation with animateTransform, one needs to specify another calcMode anyway. Maybe one should add a new calcMode 'complex' to get this effect - if needed at all for animateTransform. For the currently available methods one simply has to interpolate between the list values without a need for inversions or decompositions and problems resulting from this - especially for matrix this it pretty useful, to get stable and predictable effects for numerical calculated approximations of transform effects. Presumable with only the CSS specific and instable decomposition method it is better for this use case to continue to simulate the effect with an animation of xlink:href of a use element with about 20 references a second. >Therefore 'by' animations > on these transform functions will fall back to discrete animations and > cause the element not to be displayed for half of the animation [3]. This is another indication, that such a decomposition approach would be instable, not suited to daily/serious use and not useful/meaningful for (additive) animateTransform at all. OlafReceived on Saturday, 2 June 2012 18:03:16 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 2 June 2012 18:03:18 GMT
*