Improve DialogueAnimator performance #5

Closed
nwinter opened this Issue Jan 1, 2014 · 1 comment

Projects

None yet

2 participants

@nwinter
Contributor
nwinter commented Jan 1, 2014

screenshot 2013-12-31 19 35 07

The HUDView uses a DialogueAnimator to animate script dialogue messages in one character at a time while preserving HTML elements. However, it's really inefficient, and when the framerate is low for some reason, it can take a really long time time for the DialogueAnimator to complete (which then makes players wait a long time to go onto the next script on slow computers).

We should make the dialogue animation speed independent of any lag or dropped frames from the rest of the interface being slow, and we should probably profile it to make sure that it isn't contributing to any slowness itself.

@sderickson Did you have any ideas on a better implementation?

Related files:

@sderickson
Contributor

The current implementation is rebuilding and replacing the DOM there with every additional character, which is probably why it's so slow. Here are a handful of solution ideas.

  1. Have canvas animate the text instead. Downside would be losing HTML formatting, so many things like inserting images and text coloring and all that fun stuff would need to be somehow re-implemented or lost.
  2. Create some sort of white 'covering' element which is gradually removed from each line, making it look like the text is showing up but is actually just being unhidden. Then the DOM won't change, just the style of some covering element. The problem with that is it would be tricky to line things up and always get it right.
  3. Set the text area to use CSS ellipsis and then gradually expand the area. The problem there is how to break down the text into independent lines that can be expanded from left to right independently, and do you want ellipses in there. That would also add one word at a time instead of one character at a time.
  4. Get the animator to keep up with the clock by adding more than one character if it's falling behind. It would still be performance intensive, but it would yield to other things one the going gets rough and catch up later like the canvas does as well.
  5. Ditch it. Downside there is it's useful for getting players to see that there is text, all that movement. And it's kinda cool. But really it's not necessary, and once all the characters have moving portraits when talking, the moving text will be less important.
@nwinter nwinter added a commit that closed this issue Aug 26, 2014
@nwinter nwinter Fixed #5. 38dcb7f
@nwinter nwinter closed this in 38dcb7f Aug 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment