Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve DialogueAnimator performance #5

nwinter opened this issue Jan 1, 2014 · 1 comment

Improve DialogueAnimator performance #5

nwinter opened this issue Jan 1, 2014 · 1 comment


Copy link

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:

Copy link

sderickson commented Jan 2, 2014

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 pushed a commit that referenced this issue Jul 9, 2014
nwinter pushed a commit that referenced this issue Feb 14, 2016
clescot added a commit to clescot/codecombat that referenced this issue Jun 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants