Re: [whatwg] High-density canvases

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

> On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad <junov@google.com> wrote:
>
>> 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.
>
>
> I don't think so. Given renderedPixelWidth/Height returns the size of the
> content box, and the element's CSS width and height are not 'auto', then
> renderedPixelWidth/Height are not affected by object-fit or the intrinsic
> size, so there is no feedback loop.
>

I agree there is no feedback loop in the browser, but the event listener
may create one. See below.


>
> 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?
>>
>
> The former.
>

I agree that makes most sense, but because the canvas width and height are
integers, there will be some numerical instability and the aspect ratio may
drift over time as the canvas gets resized multiple times in succession.
This is because the intrinsic size used to compute the the new
renderedPixelWidth/Height is presumably the renderedPixelWidth/Height from
the previous resize iteration and so-on.


>
>
>> 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.
>
>
> We don't implement object-fit in Gecko yet, but when we do the change to
> the intrinsic size will trigger a relayout that will end up not change
> anything so there is no feedback loop.
>

Whether or not there is a feedback loop is not entirely up to the browser.
It depends what the event listener does.

Control flow:
1) CSS size of the canvas is modified
2) layout -> renderedPixelWidth/Height are recomputed based on the new
content box dimensions
3) if renderedPixelWidth/Height are unchanged jump to step 7
4) renderedsizechange event is fired
5) renderedsizechange event handler changes the canvas's intrinsic size.
6) if the canvas's intrinsic size changed and the element uses object-fit,
then jump to step 2. (feedback loop)
7) Paint page content

For this not to loop indefinitely depends on the event listener having
stable behavior. If the listener just sets the canvas size to
renderedPixelWidth/Height, I am pretty sure this will always be fine (two
pass layout). But in the case where the event listener does something like
this, it may take several more layout iterations for things to stabilize,
or it may oscillate indefinitely.

Example of a problematic renderedsizechange event listener:

canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale);
canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale);

This behavior seems sound at first glance, but because that arithmetic may
induce a change to the intrinsic aspect ratio due to rounding, step 3) may
not jump out of the loop during the second iteration, thus allowing the
feedback loop to keep spinning.

   -Justin


>
> 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 Friday, 27 June 2014 15:41:41 UTC