Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 4:20 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> 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?

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

Received on Monday, 23 June 2014 20:54:55 UTC