- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 20 Jun 2014 11:20:46 +1200
- To: Kenneth Russell <kbr@google.com>
- Cc: Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, Dean Jackson <dino@apple.com>, Stephen White <senorblanco@chromium.org>, WHAT Working Group <whatwg@whatwg.org>
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell <kbr@google.com> wrote: > It is a little unfortunate that a canvas-specific solution is needed. > Is it known whether document.getBoxQuads solves this problem in > Firefox? > It doesn't. Gecko (and I assume other engines) typically snaps CSS box edges to device pixel edges at render time, so that CSS backgrounds and borders look crisp. So if a canvas has a CSS background exactly filling its content box, our snapping of the content box is what determines the ideal device pixel size of the canvas buffer. Authors can estimate the canvas device pixel size using getBoxQuads to get the canvas content box in fractional CSS pixels and multiplying by devicePixelRatio (assuming no CSS transforms or other effects present). But if that estimate results in a non-integral device pixel size, there's no way for authors to know how we will snap that to an integral size. We could move these attributes up the element hierarchy, or better still to a new generic API that works on all elements (e.g. some variant of getBoxQuads). (CSS fragmentation might split an element into multiple boxes with different sizes.) I don't know of any good use-cases for that, but maybe there are some? Rob -- 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 Thursday, 19 June 2014 23:21:13 UTC