[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.
export-frame.patch
Description: Text Data