W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2010

Re: 2D Transforms Update

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 1 Oct 2010 14:37:59 +0200
To: public-fx@w3.org
Message-Id: <201010011437.59634.Dr.O.Hoffmann@gmx.de>
Hello,

some questions/comments about the current draft from today
http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

a) from previous discussions I got the impression, that the properties
defined here are almost independent from the transform attribute
used currently in SVG (1.1, 1.2), however the samples in the draft
seem to indicate, that these properties - at least the transform -
are availlable too as (presentation) attributes in SVG - what applies
and how to care about backwards incompatibilties?
For example the different syntax for rotate and the most problematic
initial value of transform-origin?

The section 'How to read this document and give feedback' suggests
the use of a switch for backwards compatibility. But how to use it, if
old attributes and new and incompatible presentation attributes
are not distinguishable by syntax?
My suggestion: Provide an example in the draft how to do this.

Obviously further questions/problems on how to use these new properties
especially in SVG depends mainly on this question, therefore currently
I have no idea, how to note these properties or how they interact, if
the property is applied to an element, that has already an old
transform attribute. And it seems to be still a secret, if  the property
transform-origin has any influence on the appearence of the old
transform attribute, what would be very confusing for many SVG
applications and destructive for existing content.

b) Related are questions about animation -
priorities and interactions between CSS transitions and animations
and SMIL animations and whether the new properties are animatable
in the SMIL sense and whether there is a relation between the animation
of a transform attribute and the property - all this seems to be an open
question in the draft.

c) Does an animated transformation (or animation of the content of
a property transformed element) have any influence on the 
transform-origin 50% 50% - could be very funny and frustrating for
authors to get wild moves of the initial value due to changes of the 
bounding box ;o)
What happens, if the element (sometimes) has not boundingBox,
for example a rotating line or another object, scaled one dimension
to zero?
To say that the intial value becomes 0 is not necessarily useful for
one dimensional objects, for them there is a need now to define 
a boundingBox for transform-origin's initial value.

d) Some transformation functions (section 'Transformation Functions')
have values like <angle> or <translation-value>.
Does it imply additional unit identifiers in SVG or in CSS?
For example for CSS angle is currently (CSS2.0 or CSS3 draft, 
not available at all in the referenced CSS2.1) only available
for aural style sheets and requires a unit - I assume that the transform
property will be applicable not just for aural style sheets in the future
and hopefully the angles will not be normalised if applied to rotations,
as currently required in CSS.
In SVG currently the values are always defined as numbers without 
units.
The samples seem to be mixed, for SVG the number variant seems
to be used, for CSS the unit variant preferred, but not in example X.
What applies?

It seems to be useful to mention/define exactly what the
values are for CSS (not aural style sheet) and SVG - at
least as a note for CSS until the CSS3 draft becomes a
recommendation or a reference to current or applicable
definitions in SVG.

e) Due to the incompatibilies between the properties and the 
the current transform attribute and the completely different
behaviour for animation, I think, the best approach would be to
define the transform property effect as an additional transformation
applied before or after the effect of the transform attribute is
applied. To avoid as much confusion as possible it should be
specified as well, that the properties are not animatable in the
SMIL sense (because the decomposition model is anyway
incompatible with SMIL animation and is only applicable for
CSS animations and transitions). Authors can still use the
SMIL animation for the attribute and the CSS animation/transition
for the property.
Would be even better to give it a different name, like transform2D
(or already transform3D to prepare for that draft).

f) Because there are advanced applications especially in SVG, I think
authors should have the choice to define the interpolation method
between matrices. Decomposition is useful sometimes for a rough
approach, however to interpolate between the values as in SMIL
provides a simpler understanding, is more predicable and is therefore
much more simple for authors how generate values lists with programs
to ensure the required accuracy for there desired effect. I think, with
decomposition practically authors always have to provide about
10-30 values per second animation to ensure, that the decomposition
has no surprising effects - and there will still be problems left due to
the requirement to determine the inverse of a matrix numerically
for this approach. The inverse does not always exist and the numerical
process to invert numerically can implicate major incaccuraries and
will be a typical problematic area to stress the implementation about
the SVG requirement of a precision of better than one device pixel.
Several applications require a more stable and effective/faster method 
to interpolate.

Note that different from typical CSS decorated content, especially
SVG tiny 1.2 has features, that can result still in visible graphics, even
if the inverse of a matrix does not exist. This has use cases and
applications and can appear intentionally or unintentionally with or
without animation. Every method, that requires the determination
of the inverse matrix must cause problems either for the implementation
or for the author of the document due to useless behaviour of viewers
in such cases.
For example it is mentioned in 'Transitions and animations between transform 
values':  'For example, an animation in which scale moves from 1 to -1. At 
the time when the matrix is in such a state, the transformed element is not 
rendered.'
Using specific features from SVG tiny 1.2 it is surely not the intention of
the author, that just for this interpolation step the object is not rendered,
if it is visible else all the time due to a remaining stroke (vector effect) 
or a constrained transformation. 

By the way, what does it mean, that in 'Matrix decomposition for animation'
it is mentioned: 'When interpolating between 2 matrices, each is decomposed 
into the corresponding translation, rotation, scale, skew, and perspective 
values. Not all matrices can be accurately described by these values.
Those that can't are decomposed into the most accurate representation 
possible, using the technique below.'
I do not understand this sentence. Is it incomplete? 
How can they be decomposed, if they cannot be accuately descirbed
by these values? Are there known examples of matrices, that cannot
be described as a group of  translation, rotation, scale and skew?
I think, any matrix can be represented with a combination of those
specific transformation. It is just not always possible to use the
pseudo-C-code from the draft to determine such a representation,
because it requires unfortunately an inversion - this is more a
problem of the used pseudo-code, not of the idea of decomposition
(however I did not prove this assumption yet - but at least if someone
provides examples, I think, I will always be able to find such
a representation or even more than one :o).
What happens to 'those' if thy cannot be decomposed with the 
given pseudo-code? 
What happens with the animation, if one value is one of 'those'?
What happens with the author intended applications and use cases for
'those'?
Does it mean, that authors have to blow up the file size dramatically 
as currently for matrix in SVG with frame based discrete animations in 
'those' cases?
Typically those will be the problematic cases from above, that would be 
no problem at all with interpolation between values ;o)
Therefore authors should at least have a choice to avoid inversion
problems for more advanced applications, that will appear at least in SVG
content.



Best wishes 

Olaf
Received on Friday, 1 October 2010 12:45:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 October 2010 12:45:18 GMT