On 2018-01-26 13:56, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 26 Jan 2018 11:08:17 -0500
>>
>> But do you think it's better to save the image, rather than what x-export-frame currently does?
> 
> Yes, I do.

Understood, thanks.  Here's a first draft of the patch.  I have a few questions:

* Is there a way to wrap 'attributes: noreturn' in a preprocessor directive? I used an auxilliary C function instead because of that.
* Is it OK to reuse `frame' after calling `decode_window_system_frame (frame)'?
* What would be the proper way to save the output of Fx_export_frame (there's a FIXME at that point in the code)?  I could either use a_write on the actual string data, or add further branches to x_cr_export_frame to write to disk directly.
* x_cr_export_frame does a number of things that I don't understand too well:
    specbind (Qredisplay_dont_pause, Qt);
    redisplay_preserve_echo_area (31);
    block_input ();
    record_unwind_protect (x_cr_destroy, make_save_ptr (cr));
    x_clear_area (f, 0, 0, width, height);
    expose_frame (f, 0, 0, width, height);
  Do I need any of these in x_gtk3_export_frame?
* The docs of gdk_pixbuf_get_from_window say that "If the window you’re obtaining data from is partially obscured by other windows, then the contents of the pixbuf areas corresponding to the obscured regions are undefined".  Is there a way I can check for that?

Once the API is stabilized, I'll write a proper commit message and documentation.

I made it possible for the function to return a string instead of writing to disk to save time (I'm hoping to make Emacs screencasts).  One issue is that the cast to an Emacs string is still quite slow (quick benchmarks: I did 200 screenshots with xwd, with my new function saving a png and then a bmp into a string, and with my new function saving a png and then a bmp to disk: 1.82s, 5.1s, 1.84s, 5.2s, 0.7s[!]).  Is there a trick I could use to make image capture faster?  Could I store the GdkPixbuf directly into an Emacs image and save it later?

Thanks a lot!

On 2018-01-26 09:45, Stefan Monnier wrote:
> And which code to use should be based on dispatching on the frame type
> (so it can work even if we have several different kinds of frame types:

I'm not sure I understood this right.  Does the patch below do what you had in mind?

Cheers,
Clément.