Initial work on firefox compatibility

[mstade]

I basically yanked out the WebkitCSSTransform usage and replaced with simple array manipulation. It seems to work as it used to, I don't think I screwed anything up.

The visual fidelity of this isn't quite on par with the Chrome version, so there's some tweaking to be done. Also, the perf isn't great so I'll look into optimizing it some.

This is work in progress.

[mstade]

I made a change to reuse DOM elements instead of recreating them, and it seems to speed things up significantly in Firefox. It has little noticeable effect in Chrome, but at least doesn't seem to slow anything down so that's good. I did some profiling in Chrome and generally it looks pretty efficient. Over a 10 second recording session I measured the following:

1.35 s Scripting
846.414 ms Rendering
548.338 ms Painting
691.618 ms Other
6.58 s Idle

Minimum Time: 1.520 ms (658 FPS)
Average Time: 16.667 ms (60 FPS)
Maximum Time: 18.437 ms (54 FPS)
Standard Deviation: 0.733 ms

So well over 60% is spent idling in Chrome, that's nice. In Firefox I don't have access to a profiler as advanced, so I don't have any actual measurements, just eyeballing. But it's definitely faster. Still some hickups though, which I don't know for certain where they're from. My guess is that it's the GC kicking in to collect old arrays and other throwaways that the code generates, because it happens at fairly regular intervals. Inspecting the memory timeline in Chrome shows the familiar sawtooth pattern, I'd be surprised if this was very different in Firefox:

This graph shows that around the second marks or so, the GC kicks in to collect. This isn't noticeable in Chrome, but like I mentioned taking a wild guess I'd say this is where the hickups in Firefox are. I'll do further research and see if I can figure it out.

[mstade]

I was looking into why the edges are so jagged in Firefox as well, and it turns out it might just be a bug. Anyway, I added outline: 1px solid transparent; to the .wing class and it seems to at least make things better but not good. I don't think there's a lot to be done about that, short of possibly considering going down the webgl route.

[iamralpht]

Good find! I wrote up the method everyone else uses on the Mozilla bug. Maybe making a bigger transparent outline would help (depending on how it ends up being sampled; it probably wouldn't help very much though).

Recycling the elements will probably help everyone a bunch, too, since churning the DOM triggers a full style recalc on WebKit (whereas poking the non-layout properties directly just invalidates the style of the node). Fortunately we don't have very many nodes or styles here! Probably the garbage is all old wings, too.

[mstade]

That's very cool, thanks for adding that to the bug – I learned something! :o)

I tried a bigger outline, but couldn't make out a difference. Maybe there is, but not discernible I think.

You're absolutely right about the DOM elements, which is why I figured it was probably the lowest hanging fruit. Other garbage is of course the arrays being created as the transformation matrix is being built, which I think is ~240 per frame, or ~14400 at 60fps; and some other things like the color objects. Only the color objects are referenced, and since we recycle the wing objects this means they live past the scope of the render function, which the arrays don't. I'm not too familiar with how Firefox deals with such ephemeral objects, but it would make sense to me if these weren't very expensive and in that case probably aren't the cause of the hickups. I'll see if I can slice out some time to get some actual measurements though, so I can stop guessing. :o)