Re: Redisplay hook

[raman]

Clément Pit--Claudel <address@hidden> writes:

Could you try capturing audio as well? Would help recording demos of 
emacspeak:-)> 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.
>

--