Smoother Transitions

Hi Rob,

I am aware that drawing performance is an issue, especially with presentation containing a lot of objects or large bitmap images. As I understand it, the drawing performance is, of course, influenced by the CPU speed and available RAM, but also depends on other things like the rendering engine. WebKit, which is used in Chrome, tended to perform better on my platform than Gecko (used by Firefox).

The way it works at the moment is that JessyInk draws a maximum of 33 frames per second, which should be plenty to get smooth effects and transitions. After drawing a frame, JessyInk checks how much time passed between the two last drawing operation and adjusts the idle time accordingly (i.e. if it took longer than 30 ms, there is no idle time).

Furthermore, the effects and transitions are written in such a way that the should usually play in a time span, which is very close to the settings chosen (i.e. if you select that the transition should take 1 s, it should not take much longer than that). I did implemented the effects and transitions this way to avoid that presenters have to wait for ages for an effect to finish playing. When I present, I always feel that these waiting times are very disturbing. The trade-off is, of course, that fewer frames will be drawn, if drawing is slow. This would in turn lead to less smooth effects.

A new feature in the upcoming version 1.5 is that drawing is suspended until all effects for one time step are processed. This should increase the drawing speed, as all changes can be drawn at once.

I invite you to try the latest development version of JessyInk by creating a branch from the launchpad repository and/or to send me an example file, where the problem occurs. Maybe there is still something that can be done on the code level to improve the performance.

Cheers,
Hannes

I have noticed the fade transition is slow as well.

Do you have access to bitmaps of fully-rendered slides? If so maybe one way to speed things up for fades would be to

1. Render and buffer the current and next frame at the current resolution in the background.
2. During the fade transition, do an alpha blend between the two bitmaps instead of rendering at each step.
3. Do a final re-render at the final step (would not be visible but could remove any lingering artifacts)

This could work for zoomy stuff too by buffering the current frame as a bitmap at the resolution required by the next zoom level.

Actually, having the next frame buffered would make the whole presentation feel a whole lot more responsive. RAM is cheap :)

Nice work on this thing. I'm going to try it out on Tuesday!

-Jack

Hi Jack:

Thanks for the comment. I am afraid I don't have the low-level access to implement the double buffered graphics you describe. Also, I would see that kind of implementation detail to be best dealt with by the browser. Apart from hints like telling the browser when to interrupt the normal update cycle of the display to draw several changes at once (suspended redraw), I also thought about moving some effects to CSS instead of JavaScript. In this way, it might be easier for the browser to anticipate what the next slides will be and optimise the performance. However, I am not quite sure this will work for every effect.

Other than that, I hope you have fun playing with JessyInk and should you discover some way of improving the performance, find a bug or have feature request, please let me know.

Cheers,
Hannes