On Thu, Jun 19, 2014 at 4:20 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell <k...@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?
It's hard to predict. A more general API would be better than a canvas-specific one, assuming it solves the problem. getBoxQuads can return different types of CSS boxes (content, padding, border, margin) -- will it be obvious to web developers which to use, and is it more likely all implementations will handle them all correctly rather than a couple of new properties on the canvas? Could you suggest a name for the new API? getBoxQuadsInDevicePixels? getDevicePixelBoxQuads? -Ken
