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

Date: Sat, 28 Mar 2009 19:17:06 +0100

To: www-style@w3.org

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

Date: Sat, 28 Mar 2009 19:17:06 +0100

To: www-style@w3.org

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

Dean Jackson: > On 28/03/2009, at 6:23 AM, Dr. Olaf Hoffmann wrote: > > Chris Marrin: > > > > .... > > > >>> Well, then explain a simple approach for authors to specify an > >>> animation (direct interpolation) between matrix A and matrix B > >>> with an accuracy better than one device pixel. > >>> If you can do it with the current draft, then I'm almost convinced, > >>> that at least nothing is missing, even if other things are available > >>> twice. > >> > >> I'm not sure what you mean by "better than one device pixel". > > > > That is a requirement for example for SVGT1.2 and SVGT1.1, one can > > simply test (and for several tests WebKit is already better with this > > as for example Opera ;o) > > I have no idea what point you're trying to make here. There is nothing > in the CSS proposal that would break accuracy in this way. > If you meet this requirement, there is typically no visible difference between an approximation/improvisation and the really intended behaviour. If the differences are larger, obviously the approximation is not good enough and has to be improved. I cannot see the problem to understand this, if something has to be checked, this happens always within some allowed error margin and some statistical assumption of what is good enough and what not, this does not depend on feelings, but on measurable entities like this device pixel. > >> If you > >> have a matrix with just translation values, for instance, then matrix > >> animation would animate from one to the other just as accurately as > >> animating the components directly. > > > > No. It is noted: > > > > "If the ‘from’ and ‘to’ transforms are both single functions of the > > same type: > > .... > > For matrix: > > the matrix is decomposed using the method described by unmatrix into > > separate > > translation, scale, rotation and skew matrices, then each decomposed > > matrix > > is interpolated numerically, and finally combined in order to > > produce a > > resulting 3x2 matrix. > > " > > That is in general not the same a to interpolate between the > > components of > > the matrix. > > Chris Marrin's example was "matrix with just translation values". When > you decompose that using the method we describe and animate, things > will work fine. > I cannot see, how your comment is related to the discussed problem. Obviously for translation there is never a problem, but this is not the problem here. With a general matrix animation there are some matrices with the same result with and without decomposition. But there are others, for which it makes a difference. I care more about the general case, where it makes a difference as for the others. Maybe Chris Marrin draw the wrong conclusion from a too simple example he has choosen. There is no need to follow him, drawing wrong conclusions too. > > If I want to do exactly this, the decomposition causes a lot of > > trouble, > > because one has to work around it with a lot of values within the > > animation > > and one has to calculate carefully, > > As I've said before, the goal is to do the right thing for authors in > the majority of cases and to allow them full control if they are like > you. There is nothing stopping you from decomposing your matrix in > advance, anyway you like. > The opposite is the case, if only decomposition is available for the matrix type, I have to work around this decomposition to get the intended effect to interpolate between two matrices. I do not want do decompose them myself, I simply want an animation interpolation between them. To do this, instead of noting for example the two matrices, I'd like to have the interpolation between, I have to provide about 10-20 matrices per second to get approximately the same effect with decomposition as without. And I still have to check, if the approxmation is proper enough. This is a lot of unnecessary work just due to the decomposition problem, I'm not even interested in, in this case. > We're telling you we came up with this approach and documented it > because it is what we found to be best. You might not agree, but you > also have not actually tried it, nor given us any examples that are > impossible/broken with our current approach. > As I already wrote, I tried it, therefore it is not helpful for the discussion to claim, that I did not try it, because I know best, what I tried and what not. What I tried is the interpolation between two matrices A, B with the current Matrix C, time t from 0 to 1: (*) C(t) = Bt + (1-t)A And you noted already an example on your own, which makes a difference: "Imagine animating from [0.707 -0.707 0.707 0.707 0 0] to [0.707 0.707 -0.707 0.707 0 0], which is an animation from 45 degrees to -45 degrees. Without decomposition at 50% you have [0.707 0 0 0.707 0 0], which is a rotation of 0 degrees (this is correct) but with a scale of 0.707 (definitely incorrect)?" Due to the formula above what you noted to be incorrect is correct and what I need. To fix this with an implementation of decomposition I have to provide a large list of matrices for the animation, that the effect of decomposition becomes neglectible. Because you claimed, that authors can specify what the need/want, I just asked for a simple method to derive this large list to get an approximation within the error margin of one device pixel. Chris Marrin claimed in his mail the formula (*) will be applicable for animation of a matrix only case, what would be fine. Obviously for too simple examples there is no difference between with and without decomposition, what does not help for non trivial examples. Therefore I had to point out, that this is not true according to the prose of the current draft for a general matrix animation. > > how small the steps have to be to > > meet the 'device pixel' condition. > > Note that SVG does not say you need device pixel accuracy during an > animation. It was only my requirement for the list of matrices to approximate the behaviour without decomposition with a viewer, which performs the decomposition, in case I need the animation without. Some authors may have lower requirements to the qualtity of approximation, some higher. The choosen value is not very important, the method to meet the requirement for the author with his computation/workaround is interesting. If you claim that it is no problem for the author to specify the intended animation with the current set of possibilities, we have to note an error margin, which is no problem for me as an author to prove your claim. Up to know, you did not offer such a method, therefore my assumption still applies, that it is not trivial to create such a list, for example for the task mentioned above. Maybe I'm wrong with this. You simply can show me the list together with the method, than we can check it somehow and then we will know, that it is (not) trivial for you to solve the task. In the best case, I learn something. In the worst case, we learn both, that it is not trivial for us to provide such a list for an approximation with the noted requirement. Maybe someone else knows it better. If not, it seems to be a good idea to provide a method to interpolate between two matrices without decomposition, either instead of decomposition or additionally. Off topic: [ SVG does not claim something different for animation, it is noted, that the display has this accuracy. If I manage to show somehow, that the difference is larger, than the viewer does not meet this requirement. > How could it? It doesn't require any particular frame rate, > so you never know exactly what will be rendered at any time. Because it is only about what is displayed, you just have to check it for each frame, not for any time. However because in SMIL animation it is possible to end an animation at any time, it is no big problem to check that at least frozen values are correct in the next displayed frame. And SVG does not mention at all, that frame have to be used, some future devices may be able to create it really continuous as intended by the author. But this is not much related to this much simpler CSS animations. It does not even have some information about accuracy, therefore my assumption is, that if I manage somehow to show visible deviations, than a viewer has already failed. ] > > But whatever, we're not breaking that. > I do not claim, that you are breaking something, because you did not even start to provide a method or list related to the task. It is no implementation but a simple sample showing that it is simple for an author to note, what is intended in a specific case - in this case an animation interpolation (*) between two matrices. > >> Same for scale and rotation. It's > >> when you combine everything that things get interesting. And in that > >> case, we believe the author's intent is to go from one "pose" to > >> another in the most natural way. For instance, if one pose is the > >> object at a scale of 0.5 with a slight cant up and to the left and > >> the > >> other pose is the object at a scale of 1 with a slight cant up and to > >> the right, then we believe the author's intent is to smoothly scale > >> up > >> the object while at the same time pivoting from left to right. And > >> that's what you would get with matrix animation. For instance: > >> > >> from: -webkit-transform: scale(0.5) rotateX(15deg) > >> rotateY(-30deg); > >> > >> to: -webkit-transform: rotateX(15deg) rotateY(30deg); > > > > I count this as 'stupid notation', if an author does it - ok and we > > all know, that authors will do this, if there is an effect. > > It's not stupid notation. It's easy for you to assume it is stupid if > you're only thinking of two states, but imagine a case where you are > transitioning between thousands of states (a pretty common thing if > you consider the complexity of a modern UI). It is not always > practical to author each state with the same list of functions. > Yes, maybe, it saves some space if the missing transformations are added automatically. However with decomposition the result gets opaque for the author. Just for clarity and to be sure, that really happens, what is intended, most authors will note the complete set just to be sure, that the decomposition does not create something different than intended. > I would consider this way more common and useful that people who > reduce everything to matrices up front (which is the only case you > seem to be concerned with). No, because most people are not familiar with matrices, they will not use them at all and prefer to specify a list of other transformations to get the desired effect, because it is simpler to identify the effect of rotation, translation, scaling and skewing separately. Only those people will calculate and use matrices for an intended effect, who know to work with it. I do it, but if I need a rotation followed by a skewX, a translation, a rotation, a skewY, a scale, a rotation, translation, skewX again, rotation, etc, I certainly will note exactly this long list instead of computing the matrix, because the matrix animation will typically result in something different (with and without decomposition for the matrix). Therefore I would only note a matrix, if I know what I do and if I need an interpolation between two matrices - for whatever reason. > For one, that means they are probably > using a tool of some kind. > > > But such funny cases are not in the center of my interest, because > > it is simple for authors to provide two sets fitting together to avoid > > such a problem. > > It isn't always simple. > > > Whether this is tried to fix somehow or whether > > nothing happens to indicate that the author should note unambiguously, > > what was intended, is a matter of taste... > > Again, we want good taste in the most common cases. We are giving you > the option to eat something really awful if you want to. > Currently not, this is the main issue of this discussion. I cannot do, what I need, because the matrix is noted to be decomposed for animation. > >> This can't do a component by component animation because the > >> functions > >> don't match. But a decomposed matrix animation would give you the > >> desired result. > > > > If the matrix animation is left to animate between the components, > > this can be simply used to trigger the decomposition: > > > > from: -webkit-transform: scale(1) matrix(...); > > to: -webkit-transform: matrix(...); > > > > then results in a decomposition and this one not: > > > > from: -webkit-transform: matrix(...); > > to: -webkit-transform: matrix(...); > > To repeat myself again, we want to do the right thing for the majority > of authors. If you don't like the decomposition you have the ability > to make your single matrix into a list of matrices. This contradicts with your claim above to allow authors to shot theirselves in their foot if the would like to ;o) I agree, that most authors would not like to do this, but to exclude this excludes intended use cases as well. What is awful or not, is sometimes a matter of taste, what can be quite different for different people, therefore it should be not the target of the draft to teach authors good taste in the sense of the draft authors. It should allow authors to do what they currently need in a simple way, if possible. > > >> And linear interpolation of the matrix values would > >> give add a implicit converse scale that would interfere visibly with > >> the smoothness of the scale from 0.5 to 1. > >> > >> Do you have any practical use cases where a linear interpolation > >> would > >> do something reasonable (much less preferable) where a decomposed > >> matrix would not? > > > > I think, I already noted IFS (iterated functions systems, done with a > > cascade of nested use elements in SVG for example), they are often > > used with a matrix as generator and can create something like > > tree structures or leafs, fractal structures - to animate those > > matrices can result in quite interesting effects (assuming that the > > processor is fast enough to compute this, well we have CUDA-GPUs > > today with more than a Tera-FLOP, but if the author is careful, > > with a simple sample this works pretty good already with an > > ordinary 10Giga-FLOP processor). > > But if you have both an IFS with recursive used use elements > > and you have to work around the decomposition of a matrix > > doing a lot of number crunching again to get a proper animation > > with a lot of values, this will get soon to much and the simplicity > > of notation for IFS is lost again. > > But you only have to do the number crunching at author time. And if > you wanted simplicity you would use the component functions like > rotate rather than matrix. No, IFS are often pretty simple for the author, most of them can be simply hand coded. This is the advantage of vector graphics. And if both is available, lists of 'simple' transformations like rotation, translation, scaling, skewing and simple matrices, there is no need to calculate something for authors. This happens only, if either the simple transformations like rotation would not be available or the matrix interpolation is not available, in both cases authors have to start nasty number crunching to realise/approximate the not available variant with the available variants. For IFS (with SVG, for (X)HTML this is possible too, but not trivial, because there is nothing like the use element; object or iframe maybe, but with this there is no control on the depth or recursion - ugly for the viewer) the files often are only a few kilobyte, but the viewer has to crunch for a few seconds to get the result. > > Anyway, I'm not sure you answered the question. Can you show me why > the decomposition is not reasonable and, more importantly, unavoidable > in this case? Because the author will note the list of rotation, skewing, scaling, translation, if this is convenient and results in the intended effect and will note a matrix, if this is preferred and results in the intended effect. For a static image the effect is the same, but not for animation. And what the intented effect is, is the problem of the author, not of the implementor of the viewer. If something is not available, the author has only the choice to skip the idea at all, to use another format or to work around the limitations with some approximations and tricks, what often implies a lot of knowledge, time and computation. It is possible too, that some authors might prefer to have a decomposed variant for their matrix animations, if available. Then it would be the best for authors of course to note, whether they need decomposition or not. However, even if not available, it is simpler to note the explicit decomposed list resulting in exactly the intended behaviour manually as in the other case to approximate only the intended effect, because it is simply not possible to write it down exactly due to limitations of the used format. > > >>> And it does not solve the possible mathematical problem with the > >>> inverse, just to believe, that it works ;o) > >>> I had already similar discussions to fix such believes for > >>> constrained transformations in SVGT1.2. > >> > >> A non-invertible matrix would result in nothing rendered, so what > >> practical use do you have for them? Again practical examples would be > >> helpful. > > > > Ok, an author may want to start or end something as an 0D or 1D object > > to fade in or out an object - nasty, if it just does not work, > > because there > > is a problem with the decomposition, the author does not really need > > to > > fade in or out. > > Wait. Have you actually tried this? I have, on both a system that > decomposes (CSS) and one that does not (SVG) and it worked fine (it's > a miracle!!) > As already noted, I use no C, therefore I cannot simply embed the C-code provided in the draft to simulate the behaviour with decomposition. Concerning 3d transforms the perspective transform is missing as matrix/formula, the skew is ambiguous, therefore I cannot simulate this currently. The animation strategy is quite different from the SMIL/SVG animateTransform with possible additive behaviour and postmultiplicative operation, therefore it will take some time to write scripts simulating this CSS approach anyway. And the code - as far as I understand this - notes only to calculate the inverse, nothing about the problem, the inverse might not exist. Chris Marrin claimed above, that nothing is rendered. If WebKit manages this anyway with the intended display within the progress of animation, this is pretty good, but has to be noted in the draft in a readable and understandable way (not just the C-code), to ensure, that any viewer will manage this. I have seen already crashes with nasty SVG transformations, because obviously 'shit' happens in some implementations, if those problems are not mentioned at all. > > Obviously the author can do this with scaling too, not just > > with matrix, but with matrix this can be simply generalised to get a > > less simple effect to avoid, that it gets boring to the audience soon. > > I'm missing your point by now. See above - it works. We made an > implementation decision to not make the author's computer explode when > they generate non-invertable matrices. Good decision - note, what to do in the draft for other implementations, because most people do not need exploded computers ;o) > > > In an animation with more than two values an author may want to > > mirror an object, setting explicitly one value to a lower dimension. > > > > Note, that with vector-effect non-scaling-stroke of SVGT1.2 it is > > possible to keep such low dimensional objects visible, this can > > result in other interesting effects with animated objects or animated > > transformations. > > Yes, agreed. And nothing we've done will break this. > > At this point I'm beginning to think the conversation is becoming > useless. Is there anything you can come up with that will be more > convincing? Remember, here are the requirements: > > 1. most common cases work and look best > 2. other approaches are possible > I agree with this, I just want to ensure, that 2. really works, what currently seems not to be the case for matrix interpolation (*). I can see two options: 1. no decomposition for the case of a matrix as transformation 2. some property or other notation to switch on and off decomposition for the matrix case. The first option is not very convenient for those people, who expect something of simply appearance from matrix animation, however, they have at least the chance to note the list of transformations (without matrix) to meet their expectations. The second option could satisfy those people as well as those, who do not need/want a decomposition, because the have other intentions. > It would help if you provided real examples, as in a piece of code > that would be what 99% of people would author and that clearly > produces an incorrect result in the current system. > > Dean Because I do not know 99% of people, I can only povide samples and simulations I have, I noted them already. I do not have to realise everything, what I have in mind, because a lot of those things I can simply describe and imagine. However, I think, the 'HTML5' WG learned already, that more than 90% of authors are doing it wrong anyway, from this point of view, we can assume, that in this range authors do not even know, what they really want or how to realise it correctly. But if everything is removed, what can be dangerous for them, there is a good chance, that possibilities are removed too, which could have be used to create some extraordinary and excellent content too by a small amount of authors, who know what they want and do. SVG sample/freak show (description is available in the desc element): http://hoffmann.bplaced.net/svgtest/usematrix01.php http://hoffmann.bplaced.net/svgtest/usematrix02.php (invalid SVG) sample containing not only the simulation, but an animation of the matrix type too, works with current versions of Opera: http://hoffmann.bplaced.net/svgtest/usematrix01a.php IFS article at wikipedia: http://en.wikipedia.org/wiki/Iterated_function_system Simple SVG-IFS without animation: http://hoffmann.bplaced.net/svgueb/fractal1.php The transformations are done here with translation, rotation and scaling to simplify explanations in a tutorial, however as can be seen the in the wikipedia article, authors use often matrix like operators too. Both is possible and done. Generators for known structures are typically only given in the matrix form. Solar system (no matrix, but could be improved by 3d-transforms and perspective projections): http://hoffmann.bplaced.net/svgtext/solarsystem.php I think, this still does not work with the current perspective projections of the draft and not with matrices, shows however something like the rotate3d for the Platonic solids (note the distortion of straight lines due to the perspective projection): http://hoffmann.bplaced.net/svgueb/tetraeder1.php http://hoffmann.bplaced.net/svgueb/hexaeder1.php http://hoffmann.bplaced.net/svgueb/oktaeder1.php http://hoffmann.bplaced.net/svgueb/dodekaeder1.php http://hoffmann.bplaced.net/svgueb/ikosaeder1.phpReceived on Saturday, 28 March 2009 18:32:25 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 2 May 2016 14:38:25 UTC
*