Re: [whatwg] High-density canvases

Hadn't thought of that. object-fit seems smells dangerous. I think we may
need to define explicit behaviors for renderedPixelWidth/Height for the
different object fit modes.
For example, with 'object-fit: contains', will the renderedPixelWidth/Height
be computed in a way to fill the element's content area, or will it
preserve the aspect ratio of the original intrinsic size?
Etc.

Also, with object fit triggering a renderedsizechange event, the event
listener will presumably change the intrinsic size of the canvas, which
will invalidate style (because the object-fit computation depends on the
intrinsic size), and that causes a style invalidation feedback loop.  If
the event listener just sets the intrinsic size to renderedPixelWidth/Height,
it's not so bad because the computation will stabilize after the first
iteration, so we just end up with a two-pass style computation. But if
there are tweaks beyond that, we could end-up in an oscillating state, and
the style invalidation feedback loop that would hang the browser.

-Justin


On Wed, Jun 25, 2014 at 6:52 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
>> To clarify, I think a version of option #1 would be the best way to go.
>> renderedPixelWidth would return the current canvas buffer width when the
>> canvas element's CSS specified value for 'width' is 'auto', and similar for
>> height.
>>
>
> Actually, that would break some use-cases involving object-fit, so instead
> renderedPixelWidth/Height should return the current canvas buffer width
> only when *both* 'width' and 'height' are 'auto'.
>
> 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, 26 June 2014 14:00:42 UTC