[Mono-osx] [MonoMac] CGAffineTransform question

kjpou kjpou at pt.lu
Sun Feb 6 10:55:15 EST 2011


Miguel

Thanks for the answer.

No problem and yes am aware of the other systems it just looked like a 
mixture of different systems to me instead of one common one.  I have no 
problem with it was just asking if it should be different from what the 
documentation says.

Kenneth


On 2/6/11 4:48 PM, Miguel de Icaza wrote:
>> Is there any reason for the naming convention used in the
>> CGAffineTransform structure?  When I went for the matrix expecting a tx
>> and ty (as well as a, b, c, d) had to look up which one was which.
>> Maybe adding convenience properties would help in this situation.
> I am not aware of any standard naming for 2D affine transform components.
>
> Some systems use xx, yx, xy, yy, x0, y0 (like Cairo), others m11, m12,
> m21, m22, x0 and y0 (Silverlight), Flash calls its properties a, b, c,
> d, tx, ty and libart and other C libraries use a float[6] array, where
> you get to set all values yourself.
>
> Since this s a matrix, the naming mXX as well as the xy/xx tell you
> which element of the matrix they reference, while the letters a, b, c,
> d require you to remember where those go.
>
>> Even in the following methods they are referred to as tx and ty
>>
>>          public void Translate (float tx, float ty)
>>          {
>>              Multiply (MakeTranslation (tx, ty));
>>          }
> The above are parameters to multiply the matrix, that is why you see
> tx, ty ("Translate X by..") and why in Scale you will see sx and sy
> ("Scale X by..").   Those are not directly stored in the properties,
> that would be incorrect, they have to be multiplied, as you showed
> above.
>
>> That would also coincide with the documentation.
> But we are not exposing that C method, we are exposing a C#
> constructor that does not even call C.
>
> The solution to the problem is to contribute complete docs for the
> convention that we have adopted.
>
> Miguel
>


More information about the Mono-osx mailing list