Fade duration on IE is way off in some cases

[Pr0fil3]

This was tested on multiple windows 10 laptops with IE version 11.0.49.
Using the basic function HTML5 tests on howlerjs.com with timestamp 2018-01-02 11-51-02.

Here's a video showing multiple browsers side-by-side. The laptop used has an i7-5500U and 16GB of RAM.
(The bottom right browser is Edge 41.16299.15.0)

I've tried this on other 3 laptops, one was the same model as mine, the other 2 from different brands.
Only on one of them (from a different brand) this issue was not present.

We're working on a webgl game using howler. The game sometimes locks down to 6fps only when running on IE, except in the one laptop where the fade issue is not present.

Feel free to ask for more information that may help you find the issue.

[goldfire]

I haven't had a chance to test this yet to see if it is related, but there is a commit on master (c0920a6) that isn't yet published to npm that may solve the issue.

[Pr0fil3]

I would could test it for you but I'm having issues creating a new build.

[themoonrat]

@goldfire I've created a version of the test based on the latest master for @Pr0fil3 that you'll get incoming results for. Essentially, it logs and timestamps variables within _startFadeInterval as it performs the fade in and fade out.

[Pr0fil3]

Here are the logs for the test that @themoonrat created.

chrome log.txt
ie log.txt

[themoonrat]

So, in the test case of @Pr0fil3, the setInterval is set to 20,
In Chrome, each iteration is happening pretty much every 20ms, but in IE, it's happening every 150 to 175ms.
Something is seriously messed up with your IE if, even on a basic test page, your browser is running at around 6fps!

@goldfire Looks like the solution here would be to change the volume not just by stepVol, but by a stepVol adjusted by the delta from the last timestamp for setInterval to the current timestamp for setInterval?

[Pr0fil3]

It's not only my IE. It's happening on other machines.
It's randomly jumping between 6fps and 60fps.

[koober]

@Pr0fil3 If you can't build it, you could hack howler.min.js. There's only one instance of setInterval. Just find this bit (middle-ish of file)

    setInterval(function(){s>0&&(i+="in"===d?.01:-.01)

and replace each

    .01 

with

    _ /s

(where _ = diff and s = steps )
At least that should tell you if the commit (c0920a6) we're waiting for will help you.
With this commit short fades will use fewer steps, because it looked to me like it was setInterval being too sluggish for the task it was given.

[themoonrat]

hi @koober
We've tested on the latest Howler version, and that commit doesn't help.

As explained above, the issue is because if you set the interval to put, say 20ms, it expects 20ms to have passed when the function next gets called. But if the browser is busy, the next time the function is called more than 20ms may have passed (in @Pr0fil3 's case, it's over 150ms!).

So the fix will be to have a time delta to make the function and fading framerate independent.

[koober]

Sorry, your log files looked just like what I was getting in all browsers...

[themoonrat]

In the logs, it's the "new Date().getTime():" that is the giveaway; a timestamp put at each iteration of setInterval. For Chrome, each timestamp is around 20ms different from each other, in IE it's ~150ms different from each other. So the overall fade progress looks similar across the 2, but in reality it's happening over a far longer period of time in IE.

[goldfire]

Yes, it does look like the right solution is to use the time difference as timers/intervals are unreliable. I'll look into getting this fixed and an update out soon. Thanks for testing this!