emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: x-export-frames for non-Cairo builds


From: Clément Pit-Claudel
Subject: Re: x-export-frames for non-Cairo builds
Date: Fri, 26 Jan 2018 18:13:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 2018-01-26 13:56, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> 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.

Attachment: export-frame.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]