How to take a screenshot of a window that is not visible in batch mode?

allend · 04-11-2018, 05:52 PM

Sorry - The last post is a manual technique, but the OP appears to want an unattended scriptable solution.

FlinchX · 04-12-2018, 03:32 AM

Quote:

Originally Posted by allend

Sorry - The last post is a manual technique, but the OP appears to want an unattended scriptable solution.

Yes, exactly. I don't want to perform any mouse clicks on a window to take the screenshot of it, I just want to pass its id to a screenshot taking tool. Again, it should happen in another workspace, not the active one, fully in background. And it should not interfere with the currently active workspace or any windows from it.

keefaz · 04-12-2018, 06:10 AM

The problem is that when window is in another workspace, it's not displayed so its pixels are not in current display memory. At this point no screenshot can be made until you switch to the workspace when window resides and the pixel are drawn to the screen

FlinchX · 04-12-2018, 08:11 AM

Quote:

Originally Posted by keefaz

The problem is that when window is in another workspace, it's not displayed so its pixels are not in current display memory. At this point no screenshot can be made until you switch to the workspace when window resides and the pixel are drawn to the screen

I can understand this. But since the window is still alive, its content must be somewhere in memory, no?

keefaz · 04-12-2018, 09:33 AM

Data content yes but to get a graphical view you have to draw lines, colors, points etc on screen
I mean screenshot programs don't draw from evaluated data, they copy screen pixels in a file

allend · 04-12-2018, 10:48 AM

Screen capture programs assume that they need to access the active buffer.
So in my dual monitor setup I can access the active buffer on the alternate display.
With a single screen, the only method that I can conceive that could create an alternative active buffer would be to use Xnest to create a second Xserver.
I have played with Xnest, but cannot offer any advice for this use case.

keefaz · 04-12-2018, 11:30 AM

Another idea would be to put the window temporarly in the same workspace but under a background image which would give the illusion of a non visible window

allend · 04-12-2018, 08:54 PM

Just got this to work on my little netbook.
I started a nested session running Windowmaker with

Code:

exec xinit /usr/bin/wmaker -- /usr/bin/Xephyr :1 -screen 1000x500

and then I could capture a screenshot from that session from a terminal in another workspace with

Code:

import -display ':1.0' -window 0x1000013 ~/Desktop/wsnapshot.png

FlinchX · 04-12-2018, 11:59 PM

Quote:

Originally Posted by allend

Just got this to work on my little netbook.
I started a nested session running Windowmaker with

Code:

exec xinit /usr/bin/wmaker -- /usr/bin/Xephyr :1 -screen 1000x500

and then I could capture a screenshot from that session from a terminal in another workspace with

Code:

import -display ':1.0' -window 0x1000013 ~/Desktop/wsnapshot.png

Very interesting, could you please test if it works the opposite way? I mean, run the screenshot software in Xephyr and see if you can capture a screen from main session. I will definitely test this too soon, but I'm concerned since I've read that running apps like OpenGL ones in Xnest/Xephyr may have performance penalties. So perhaps it's possible to run the screenshot software in another session, not the app that generates window that needs to be screenshotted.

allend · 04-13-2018, 08:36 AM

From my quick testing, it does not work the opposite way unless the window to be captured is in the same workspace.
I can do

Code:

import -display :1 -window 0xe00013 ~/Desktop/test1.png

from a terminal in a separate workspace on the primary display to capture a window in the Xephyr session
but

Code:

import -display :0 -window 0x2200058 ~/Desktop/test2.png

from a terminal in the Xephyr session only works if the window to be captured from the primary display is in the same workspace as the Xephyr session.
The attached screenshot may clarify.

keefaz · 04-13-2018, 09:31 AM

@FlinchX, just curious did you try the commands in post #2 ?

FlinchX · 04-13-2018, 09:52 AM

Quote:

Originally Posted by keefaz

@FlinchX, just curious did you try the commands in post #2 ?

It's my highest priority pet project for this weekend, hopefully I will provide feedback until the weekend is over, on your suggestion and the one about using Xephyr. Sometimes it takes a few days, but I value the help I get in this forum and I always try to provide feedback to people who spend their time trying to help me. You can see it from my post history.

keefaz · 04-13-2018, 11:14 AM

No problem, I was wondering if it could work (not having the possibility to test it myself)

FlinchX · 04-13-2018, 11:27 PM

Quote:

Originally Posted by keefaz

Maybe make window sticky, then unstick it with wmctrl?
Not tested (wmctrl not installed here)

Code:

wmctrl -i -r <window id> -b add,sticky
import -window <window id> window_image.png
wmctrl -i -r <window id> -b remove,sticky

second step throws an error, just like when I ran it before, without making the window sticky:

Code:

$ wmctrl -i -r 0x01800003 -b add,sticky
$ import -window 0x01800003 screen.jpg
import: unable to read X window image `0x01800003': Resource temporarily unavailable @ error/xwindow.c/XImportImage/4983.
import: missing an image filename `screen.jpg' @ error/import.c/ImportImageCommand/1287.

keefaz · 04-14-2018, 08:05 AM

Ok, it's seems dwm doesn't support sticky feature. I was worth a try though

And what about (say window is on workspace 2 and you work on workspace 1

Code:

wmctrl -i -r <window id> -t 1
import -window <window id> window_image.png
wmctrl -i -r <window id> -t 2

You may want to use wmctrl -d to verify workspaces numbers