924807 - Bad performance and invalidation behaviour on puzzle game prototype

Status: NEW

(Core :: Layout, defect)

Description

[Chris Lord [:cwiiis]]

Attachment: puzzowl-prototype.zip

Sorry for the vague bug title, but a prototype of a puzzle game I wrote exhibits both bad invalidation and bad performance in a situation where I think we ought to be better. Performance of the same prototype is excellent in IE and much better in Chrome, though both suffer from other visible bugs (that I could probably work around, if I was targeting them). The prototype is attached, controls are touch/mouse and either device motion or a/z to rotate.

Bad invalidation:

- Initially when dragging a row, all rows underneath it are invalidated. This appears to just be a bug.
- Rotating causes everything to be redrawn as it layerizes everything. Not a bug as such, but a source of slow-down.
- Getting a match (4 or more of the same colour vertically) starts an animation which unnecessarily invalidates the entire field instead of just the elements that are animating.

General bad performance:

- There is a significant delay when starting a rotation that is far less noticeable in Chrome and just isn't there at all in IE.
- Dragging rows is noticeably not smooth

All of these issues are exacerbated when running on a phone.


In general, I think this shows up a few areas we ought to improve in;

- Image caching: I assume this is slow because rendering the SVGs of the owls is slow. Given that there are only 8, small SVGs that are reused, I think this ought to get cached and be fast.

- Layerizing: Most of the time, it would be desirable to keep the layer count down. This situation, however, it would be far more desirable to keep everything in layers (especially if they could be image layers that share textures). I think our heuristics to decide when something gets layerized could be improved for use-cases like this (of which there are an increasing amount, and which work great in IE).

- Animations: It seems silly to me that if an animation involves practically any work at the beginning (which is quite likely, given our layerizing behaviour), we skip a load of frames. On mobile, this usually manifests in skipping *all* frames, on desktop this manifests in jank at the start of most animations. We should really delay animation counters until the first frame has been rendered, and perhaps introduce a threshold of some kind if that takes an inordinate amount of time (though that really ought not happen). It's quite obvious that Chrome does this (and it's not obvious what IE does, as their performance in this situation is usually excellent).

- SVG: SVG is great for little games like this, but our rendering of them is much slower than all other browsers. That said, our rendering is probably more accurate, so swings and roundabouts... But it's worth noting that the SVGs in this demo look noticeably smoother in Chrome, as well as rendering faster. It'd be nice if our SVG rendering performance (and perhaps quality) improved, though this wouldn't be much of an issue for this particular case if caching worked effectively.

I've cc'd some people I think may be interested, apologies if you aren't, or if you are and think I've missed people, please Cc them :)

Meanwhile, I'll be rewriting this using canvas like everyone else :(

Comment 1

[Jonathan Watt [:jwatt]]

I had a look at this with Cwiiis a week or so ago, and I think this might benefit from Seth's work in bug 764299. (At least Cwiiis is using the same .svg files as backgrounds for multiple 'div's that he moves around (the owls).)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Chris Lord [:cwiiis] from comment #0)
> - Animations: It seems silly to me that if an animation involves practically
> any work at the beginning (which is quite likely, given our layerizing
> behaviour), we skip a load of frames. On mobile, this usually manifests in
> skipping *all* frames, on desktop this manifests in jank at the start of
> most animations. We should really delay animation counters until the first
> frame has been rendered,

I filed bug 927349 on that.

> and perhaps introduce a threshold of some kind if
> that takes an inordinate amount of time (though that really ought not
> happen).

I'm not sure what you mean by "a threshold of some kind".