W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [matrix][cssom-view] DOMMatrix operating on single or double precision floating point numbers

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 23 Sep 2013 08:56:50 +1200
Message-ID: <CAOp6jLbyPJmhyyYaEE7MnUN0gRM4CieT8F5CajZn01Qv8KRWdw@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: www-style list <www-style@w3.org>
On Sun, Sep 22, 2013 at 1:42 PM, Dirk Schulze <dschulze@adobe.com> wrote:

> Some people objected in using double precision, since double precision
> operations can take more computation cycles, especially on mobile devices.
> The counter proposal is to use single precision floating points and
> truncate on passing double precision values. Truncation to single precision
> and expanding to double precision (for instance to return a DOMPoint) takes
> more time as well. So even that has disadvantages. Note that arithmetic
> operations in JS are done with double precision, internal operations could
> still benefit of single precision operations.
> On the other side, many implementations with at least one exception
> (Gecko) operate on double precision already. The web exposed, prefixed
> interfaces WebKitCSSMatrix [2] and MSCSSMatrix [3] for instance are
> operating on double precision values. This already causes accumulating
> errors that can be seen between Gecko's and WebKit's implementation of CSS
> Transforms when applying multiple transformations.
> DOMQuad and DOMPoint will be involved in arithmetic operations as well and
> it would be great to find a consensus on the precision question which may
> solve problems on CSS Transforms as well.

I'm OK with going with doubles everywhere.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
Received on Sunday, 22 September 2013 20:57:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC