v2: jumpy in Firefox

[tomByrer]

v2-dev today, Firefox DevEd, 46.0a2 (2016-02-15), OSX

Resizing the test page, the images (most obviously lizards & Minimum cropping region) will resize smaller than the section 'viewport' & jump back into their correct size. Oddly, sometimes won't happen if refreshed or after switching tabs & switching back. Settings on bottom don't seem to affect.

Works smooth in Chrome & Safari.

Might be part of their tweaking the renderer, so sort of known issue there.
https://hacks.mozilla.org/2016/02/smoother-scrolling-in-firefox-46-with-apz/
Also might be part of fixing another bug?
https://github.com/scottjehl/picturefill/blob/master/CONTRIBUTING.md#faq--frequent-issues

---

Thanks for the "Minimum cropping region"; exactly what I've been looking for!

[jonom]

Thanks for the report, have been able to replicate in 44.0.2. Seems to be intermittent so that's annoying :) If you find a fix feel free to open a PR, otherwise I'll look in to it when I get time.

[tomByrer]

Thanks for the fast reply!

Hmmmm Could be a timing issue &/or needs extra processing trigger when resized in Fx.
I noticed you don't use requestAnimationFrame for throttling; is there a reason for that?

[jonom]

I noticed you don't use requestAnimationFrame for throttling; is there a reason for that?

Hadn't occurred to me but browser support is a bit of a factor... not concerned about IE8 but would prefer to keep IE9 support.

It does look like this is a throttling issue, if I turn throttling off it's nice and smooth in Firefox. I think most of the latest browsers have throttling built in to the resize event which reduces the need to throttle the resize function, but would be good to have it configurable.

Any chance you want to open a pull request to introduce requestAnimationFrame support with setTimeout fallback? Example here: https://developer.mozilla.org/en-US/docs/Web/Events/resize

[tomByrer]

Well, MS EOL'd all IE<11; you'll get a nasty note when you open the browser, & IE9 is only 1% of the browser market now... either way there are polyfills.
I was thinking about lowering the framerate from requestAnimationFrame's 60FPS to something around 25FPS. Less calculations, redraws, less battery, & not sure if it would be noticeable.

[jonom]

I'm not too worried about battery life etc. since we're only talking about what's happening during the resize event. If someone is resizing their browser for more than a few seconds at a time they're doing it wrong :) but yeah 25fps would be fine by me. I changed the CSS in this version so that images stretch instead of moving in to weird places and exposing the background in between adjustFocus() calls - so keeping a high frame rate isn't so important.

I'm a fan of progressive enhancement so if it's not hard to provide a fallback and support older browsers that's what I'd rather do.

[tomByrer]

Starting to look at the code; mind if I refactor a bit first? Don't want to be picky, but I believe I can find a better variable name than a. ;)

I also noticed that you use transform-origin but not transform. I thought transform might work better, since it is GPU accelerated, & I think that top, left, etc are still not GPU accelerated. Have you tried switching yet?

[jonom]

Ha, well I know what a means :) wanted it to be short but admit it's not very transparent. Yeah you can do some refactoring, just make sure there's a good reason for anything you do and do a separate commit for each piece of new functionality so I can follow along easier. Have been meaning to try using transform if supported by browser just haven't got around to it. (Note: yes it's possible to set transform origin with this plugin but the plugin itself doesn't make use of that setting) There's an open PR for that it's just out of date if you want to look at it. Look forward to seeing what you come up with!

[tomByrer]

do a separate commit for each piece of new functionality so I can follow along easier

Sure thing, but I'm used to being told to 'squash' commits so I'll have to adjust.
Prefer smaller PRs, or 1 big PR? I'm thinking the refactoring should be a first, separate PR.

[tomByrer]

First thing I did was to reduce the image file sizes (I'm kinda nerdy about
optimization). But Github is down, so I'll send in a PR later.

On Sun, Feb 21, 2016 at 9:04 AM, Jono Menz notifications@github.com wrote:

Ha, well I know what a means :) wanted it to be short but admit it's
not very transparent. Yeah you can do some refactoring, just make sure
there's a good reason for anything you do and do a separate commit for each
piece of new functionality so I can follow along easier. Have been meaning
to try using transform if supported by browser just haven't got around to
it. (Note: yes it's possible to set transform origin with this plugin but
the plugin itself doesn't make use of that setting) There's an open PR for
that it's just out of date if you want to look at it. Look forward to
seeing what you come up with!

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

[tomByrer]

Seems some of my refactoring is also optimizing. 1 if statement removed.

Sorry I already made a mess in my commits, but you can test if I blew anything up yet ;)

Noticed that you are using an object for saving data, seems variables are faster, so that will be next on my STDs.
eg data.shiftPrimary into dataShiftPrimary or maybe just shiftPrimary. Since resizing hits this code many times/second, should help a bit.

[jonom]

1 if statement removed.

👍

Noticed that you are using an object for saving data, seems variables are faster, so that will be next on my STDs.

I'm luke-warm on this one, the idea of keeping it all in an object is I can easily get a read out of it for debugging. If you can demonstrate a significant performance gain I would be keen to see it done but otherwise I'd rather not sacrifice the convenience.

[tomByrer]

Could just remove the dot; keep readability & improve perf. Last time I checked "jsperf object vs variable" variables won. Even if I cap those calculations at 60FPS, that is still alot of lookups.

[tomByrer]

Seems removing the data object was only a slight improvement, likely as much as removing 3/4 of the element lookups.
Likely modern JS engines automatically do optimizations like this, but I put in code anyhow; less horizontal noise when eyeballing.

[tomByrer]

New PRs, but you can still read the old PR if you want to view each step.
Might add back the removal of the data object later when I can test better on a bigger screen.