Re: Redisplay hook

["Clément Pit--Claudel" <clement.pit@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2319 bytes --]

On 2016-07-04 16:37, Robert Weiner wrote:
>> Additionally, since Emacs is driving, I can record plenty of
>> per-frame data, such as which key is being pressed with each frame.
>> Here's an example, which was fairly easy to assemble using this new
>> hook and a bit of ImageMagick:
>> http://web.mit.edu/cpitcla/www/emacs-screencast-annot.gif (it may
>> take a bit of time to load). What do you think of the result?
> 
> This is great and I would love to see this as a package and see it
> explained in more detail..  A simple way to capture Emacs
> screencasts, potentially with an audio overlay, would lead to many
> more demonstrations of Emacs packages leading to broader
> understanding and usage.

Thanks Bob :) Here's a quick outline of how it's done; hopefully we can
implement the necessary hook, and then I'll make an ELPA package out of it.

Essentially, my code adds two hooks:

- A pre-command-hook, to update a variable tracking (this-command-keys-vector)

- A post-display-hook, to capture screenshots.

The post-display hook records the current time and the current value of
(this-command-keys-vector), then synchronously calls ‘xwd’ to take a screenshot
(‘import’ would also work, but it is much slower). The resulting file name is
saved into a list of captured frames (annotated with the current time and value
of (this-command-keys-vector))

Finally, to finish the capture, I run a humongous ImageMagick command to stitch
together all frames and add text overlays.  The delay between consecutive frames
is computed using the timestamps recorded in each frame.

The implementation of the full thing is pretty short (about 200 lines), and it
works fairly well.  The one downside is that the temporary files that it
generates tend to take a lot of space (about 3.5MB per screenshot). Saving
compressed screenshots is possible, but it tends to slow Emacs down more
significantly.  Of course, one could imagine capturing uncompressed frames, and
compressing them in a separate thread; I have not investigated this option yet.
Alternatively, one could measure the time taken to capture the frame, and adjust
inter-frames delays in proportion when generating the movie.

I'll send the code once I have a bit of time to clean it up.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]