W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2014

Re: [geometry] Replace isIdentity()?

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 7 Jun 2014 14:30:12 -0700
Message-ID: <CAGN7qDA1S_aoiA7NHjC_08cBx+cFtvDwKpFb_VfbKsXM6XZpGQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dirk Schulze <dschulze@adobe.com>, FX <public-fx@w3.org>
On Sat, Jun 7, 2014 at 12:18 PM, Tab Atkins Jr. <jackalmage@gmail.com>

> On Sat, Jun 7, 2014 at 8:33 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> > Other people and engineers like me believe that this is too restrictive.
> In favor for isIdentity(), even with the concerns in the introduction:
> >
> > 1) isIdentity() as currently specified must be implemented so that it
> can guarantee all of the above scenarios that maybeHasTransform() can
> guarantee as well.
> > 2) isIdentity() is nearly exclusively used to skip complex and costy
> computational operations entirely that would not cause any visual
> difference for identity. The worst case: the matrix is close to identity
> but not exactly identity and the application needs to do all these
> operations. While it can optimize other times. It could never optimize for
> maybeHasTransform().
> > 3) All browser implementations, graphic libraries, game engines use or
> provide isIdentity(). In none of the instances the mentioned problems
> caused problems beside the one describe in 2).
> > 5) Authors create DOMMatrix to transform it. In this case
> maybeHasTransform() is useless because it will then always return ’not
> identity'.
> > 6) For isIdentity(), the author can do transform operations and check at
> any time for identity.
> > 7) maybeHasTransform() can only be useful if a system API returns a
> DOMMatrix object. (There is none today but will be in the future.)
> > 8) isIdentity() can be implemented with the help of SSE and similar
> functionalities so that it is not significant more complex or decreases
> performance.
> Agree with this completely. Please keep isIdentity() as currently
> written in the spec.  The downside that some code might
> seemingly-randomly take the quick or slow path depending on precise
> operations seems better than the downside of maybeHasTransform(),
> which'll just make it always take the slow path.

'maybeHasTransform' is the API that will give consistent behavior while
'isIdentity' might act randomly.
Looking at the webkit and mozilla codebases, 'maybeHasTransform' will
almost always take you to the short path.
On top of that, it will also be faster to calculate.

> Plus, authors can write an isNearlyIdentity() method for themselves if
> they find they need it.  (We shouldn't provide this ourselves, as it's
> a footgun in most cases, and the required threshold varies by use-case
> and should be determined by experimentation.)

If they rely on matrices that are manipulated and might become identity,
authors shouldn't rely on the isIdentity method and write an
'almostIdentity' method. By providing this API, we're making a promise that
we can't keep.

Please read over the mailing list discussion especially Benoit's arguments
on why we shouldn't have this API:
Received on Saturday, 7 June 2014 21:30:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:49 UTC