- From: Justin Novosad <junov@google.com>
- Date: Fri, 27 Jun 2014 11:41:14 -0400
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: Rik Cabanier <cabanier@gmail.com>, Kenneth Russell <kbr@google.com>, Stephen White <senorblanco@chromium.org>, WHAT Working Group <whatwg@whatwg.org>, Dean Jackson <dino@apple.com>, Ian Hickson <ian@hixie.ch>
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