- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 3 Jun 2012 15:06:03 +0200
- To: public-fx@w3.org, www-svg@w3.org

Dirk Schulze: ... > > > > This applies as well for scale(0,0), scale(0,y), scale(x,0) etc, > > therefore no really new problem. > > No. As long as the third (and second) rule of [1] apply to the transform > function list, these transform functions can get interpolated numerically, > as described by [2]. [1], section 17 talks about the value 'none'. Obviously for all of these transform types one can simply interpolate between values for animateTransform, because they are always of the same type and one simply has to interpolate affine between numbers as described in SMIL. No specific rule required, no new problem appears. (We need to discuss to-animations separately, related to your current email about the issue 'about animate and animateTransform') If another interpolation method like decomposition introduces a problem for some normal values as zero, this is a problem of this interpolation method, not of these zero values and not specific for by-animations, because those are defined to be equivalent to values animations anyway. scale(0,0) and matrix(0,0,0,0,0,0) describe the same matrix. If you start to apply the decomposition method to this with the CSS transform animation, for example with animation from scale(0,0) to rotate(180) you will get the same or similar problem, probably even the same result as for from matrix(0,0,0,0,0,0) to rotate(180) - the decomposition pseudocode is too complex, that I can really predict without numerical calculations, whether the result is the same, but if it is not much worse than expected, it should be the same ;o) On the other hand, if you animate from scale(0,0) to scale(-1,-1) this is the same as to animate from matrix(0,0,0,0,0,0) to matrix(-1,0,0,-1,0,0), therefore no different situation and no need for decomposition with these variants. > > > 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. > > The quaternions try to solve other problems like the Gimbal Lock, a side > product of the decomposing of matrices. A problem that can occur with euler > angels. Well, then this change still means, the CSS method for interpolation is not good enough, because it still requires inversion. > > > As long as this is not stabilised by avoiding inversions, > > It is unclear to me what "stabilized" means for you :) For example: a) No inversion causing artifacts (for example additional to the problem of non invertable matrices this can cause often larger numerical inaccuracies, if the determinant is 'close' to zero or the matrix has a structure, that causes problem for numerical inversion - this is, what one gets served in one of the first lessons about numerical mathematics at university.) b) The effect of the interpolation is hardly to predict for the author of an document. Even looking on the pseudocode of this method, I have no idea, what will be the result of an interpolation between two arbitrary matrices and I have no intuitive idea, how this result could be related to what I will get, therefore I simply do not know, which matrices I have to note for this method to get an intended effect, therefore it is much simpler to get the effect approximately with this method of animating xlink:href of use with 20 shapes per second than to gues what might happen with this decomposition. Authors need to 'implement' the decomposition themselves, to estimated, what the effect of an animation is - which authors will do this, typically instead they will simply try to avoid this decomposition at all to get simpler predictable results. ... > > There is a whole section in the spec [4] that describe how to apply > perspective and how to multiply nested transformation functions. In general > they try to specify the current behavior of current browsers. As already discussed, there is still missing the mathematical description, how the matrixes of section 21 are related to the effect of a transformation. I think, this will be added in the future as already promised. After this is done, section 6 will be nice to help to understand this. > > > 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. > > 3D transforms are already implemented. The current behavior needs to be > specified now. This looks like the wrong order again - obviously one should first specify, what has to be done, after this one can implement, what is specified. Of course a test implementation can help, but of course this should not be available for the public, else the complete draft/recommendation is superfluous, if arbitrary things are implemented and later it is just noted a history of implementation bugs and aberrations ;o) > > I have not checked additive transform behavior on matrices for SVG > Animations on Opera so far. At least for CSS Transforms start and end > matrix must be invertible, otherwise the interpolation does not work. I did not check this as well, years ago somebody mentioned in the www-svg list, that they implemented it, I just tested, that this is true, no details - presumbly the implementation is not related to the CSS drafts, that occur now, therefore I assume they simply interpolate between the values without introducting inversion complications, because if you interpolate with animateTransform between two matrices with the SMIL concept, you just have to interpolate between two lists of numbers of the same lengths, this is simple and available already for several other attributes or properties - nothing really new to implement, one only has to ignore, that the transform type 'matrix' is not animatable in SVG 1.0, 1.1 and 1.2, this can even happen 'by accident' - the filter chapter has more complex values, which are animatable ;o) > > > 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. > > If you tested additive matrix interpolations on SVG Animations with Opera, > and if it gave you a smooth interpolation, then maybe because every value > of the matrix got interpolated numerically. Like I said, I did not check it > myself. However, for CSS Transforms it was decided, that this 'mostly' does > not give you reasonable results. Due to the inversion problem, the decomposition methods does not provide resonable results - and of similar relevance, no simply predictable results (maybe similar to a surprise egg (Kinder surprise, german: 'Überraschungsei', don't know how to translate) ... Maybe the decision makers used only examples without a relevant use case? Obviously if you calculate the matrices for translate(20,-50) rotate(30) translate(-20,50) and translate(-20,50) rotate(770) translate(20,-50) and interpolate between the matrices, you will not get a rotation of 750deg with a moved rotation center, but if you note the matrices as animation values, you do not expect a rotation anyway, else you did not understand matrices and your expectations do not really matter for the result and such an example is no meaningful test case for the decision ;o) > Therefore CSS Transforms uses decomposing. And as we can see - it fails, if the matrices are non invertable, what has nothing to do with the values to be interpolated between, just with this interpolation method. > The decomposing code in current browsers can not deal with non-invertible > matrices. As already mentioned, this indicates, that the methods needs to be improved and stabilised to avoid such strange artifacts. ... > > For daily serious use you would use transform functions that are > interpolatable by [2]. These animations make most sense, give you > reasonable results and fulfill >90% of all use cases. You mean with values lists, the same structure for every value, therefore no decomposition is required? Obviously these are the main use cases for animated transforms and we need no decomposition for them. Therefore we need to care only about use cases, that have either to do with interpolation between a list of matrices or for lists with mixed structure. I think, there is no disagreement about the majority of use cases, where you have a list of values of the same type (only available currently in SVG) or for the CSS concept to have values with transform lists all of the same structure - obviously this is meaningful and compact to be able to apply the animation to the list items. But if you allow in animateTransform now to interpolate between matrices, this is still ony type for the animation, no new problem occurs. Even for the CSS concept, as long as the author does not 'corrupt' the list item structure of such a transform list, no new problem occurs, if such an authors uses matrices. Only if the transform lists are not separable anymore into the same structure for each animation value, a problem occurs for the CSS approach, the decomposition might be a solution or an option. Else there is no need for this. I have no other use case in mind for animated interpolation between matrices as the need to have a somehow generated time dependent transform matrices, that have to be represented as a values list with a finite number of values. For this use case the interpolation between these values has to be simple, fast and stable and without artificial complications introduced by the interpolation method, not under control of the author. With the affine interpolation from SMIL it is relatively simple to predict, how many values per second are required to get a sufficient approximation, typically this will be clearly less than 20. With the CSS decomposition method, I simply don't know, because the results are not predictable - maybe you need even more than those 20 with the result, that you can forget this method at all. If you talk about >90% of use cases, this CSS decomposition is good for, you should be able to list at least ten use cases, this method is good for, because I was able to mention one important use case for the simple affine interpolation ;o) Currently my list for decomposition is empty, respectively the only use case, that came into my mind up to now, is that because the CSS approach allows to mix different types, it needs a fallback behaviour just in case an author is not clever enough to avoid the situation, that the values, it has to be interpolated between have not the same structure. Well, but this is not really a use case, it is just a fallback for awkward notations of authors. But if this is considered anyway as awkward notation, it does not really matter, what the precise effect is, therefore one still can interpolation affine between the calculated matrices directly without decomposition. If the author does not like it, this is at least a hint to fix the lists ;o) Looking at the method, I think, if one has an arbitrary amount of transforms like scaling, translation, rotation, skewing multiplied to a matrix, the decomposition of such a matrix is not even able to decompose the matrix to the same list, this means, finally the complete process is not bijective. This means finally, one cannot even compress longer lists to a matrix so reduce the file size, if the animation effect matters in detail. Therefore the 'core use case' for authors seems to be to avoid, that the decompostion ever takes place ;o) Can you list 10 meaningful use cases for the CSS decomposition method to interpolate between two matrices? Can you list use cases for the animation with mixed transform list values, what seems currently the main reason for the existence of the decomposition method? Aren't this always situations, where the author has no precise animation effect in mind anyway? The decomposition might be ok for the mentioned Žuse case' 'surprise egg', that the transform lists, to be interpolated between, are not the same, to get a somehow nice looking effect for awkward notations of authors. But if the author intentionally only notes matrices, such an author is not interested in a somehow nice looking effect for awkward notations, such an author has done own numerical calculations and needs only a simple, fast, stable and predictable interpolation as mentioned for my use case above. Olaf

Received on Sunday, 3 June 2012 13:06:35 UTC