Affine transforms - matrix algebra
pavel.safrata at oracle.com
Wed Jul 11 09:31:57 PDT 2012
On 11.7.2012 17:39, Martin Desruisseaux wrote:
> Le 11/07/12 16:57, Pavel Safrata a écrit :
>> If we are going this way, shouldn't we do also this?
>> * Rename 'concatenate' as 'prepend'
>> * Rename 'preConcatenate' as 'append'
> Yes, I think it would bring more uniformity in the method naming.
>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-)
> I missed that method... What would its function? Or are we are talking
> about something like a 'getTransformCoefficients()' method?
This method is similar to concatenate (prepend) except that it is
defined on parent Transform class and returns the result in a new
Transform instance (allows for multiplicating arbitrary - possibly
immutable - transfroms).
>> As a black-box transformation composing this makes sense. As a matrix
>> algebra, it may be also confusing: tA.append(tB) means matrix
>> multiplication 'B x A', does it sound good? Maybe yes, I'm not sure.
>> Anyway, so far the best proposal I think.
> Yes, I realize that a risk of confusion may exist. We may need to
> stress out in the javadoc that "append" is not "multiply". Indeed, if
> the "append" method was defined in the parent Transform class and if
> that parent was the base class of generic transformations (not just
> linear transformations), then the "append" method would actually not
> be implemented as a matrix multiplication except in the special case
> of linear transformations.
I don't have any better idea. Writing a clear javadoc is probably the
only thing we can do. As the methods will be defined only on Affine
class, we should probably mention specifically the relationship with
multiplication, maybe even a warning for J2D developers that this may
work the other way than they're used to..
>>> I don't have experience in this area. But naively, it seems to we
>>> that it would be better to be notified only after the full matrix
>>> has been updated...
>> Yes, I would also pick this option. It's just that it would mean
>> writing much more complicated (and a bit less effective) code so the
>> question is whether or not you think it is important.
> I don't have a use case where I would like to listen to individual
> coefficient changes. It seems to me that I would rather listen to
> whatever property contains the Transform object as a whole.
> Consequently, I don't think that the atomicity of Affine operations
> would have much incidence (assuming that there is some way - other
> than listening to individual coefficients - to be informed that the
> matrix as a whole has changed).
Unfortunately I don't think there is a way to listen for changes on an
object other than listening on all its properties. In my opinion this is
quite a big issue and it's been bothering me for some time already. I've
heard that some utilities are planned for that but still I want to file
a feature request for some better mechanism, hopefully this email gives
me the impulse to finally do it.
Anyway, I should probably not give up on the (quite obviously) better
API just because of implementation complexity. Will try to make the
More information about the openjfx-dev