screen capture takes a long time

[victorlesk]

Hi - I am running on a modern fast X11/mandriva Linux machine with an NVIDIA graphics card. My "import" commands all seem to take more than 2 seconds.

In particular

import -window root a.pnm

Takes four or five seconds.

Why might this be and is there any way of speeding it up significantly?

Thanks - Victor

[magick]

ImageMagick recursively traverses the entire X11 window hierarchy to build a proper screen shot as recommended. However, in most cases you can bypass the recursive algorithm and just take a screen shot with the -screen option.

[victorlesk]

ImageMagick recursively traverses the entire X11 window hierarchy to build a proper screen shot as recommended. However, in most cases you can bypass the recursive algorithm and just take a screen shot with the -screen option.

With -screen takes pretty much the same amount of time. I did a repeated time trial which showed that

import -window root -screen a.pnm

took about 5% less time than

import -window root a.pnm

but still is way slower that I need. Any other ideas?

[anthony]

If you X window server remote????

That is your DISPLAY environment variable contains a network name...
For example on my system

Code: Select all

echo $DISPLAY
:0.0

which shows that I am not using the network to talk with the X display server.

The network can make any sort of display communications very slow, as the display has to talk back. Often the display only has minimal back talk, applications usually do all the talking, making it work quite fast (one direction).

[victorlesk]

Good point - but it is the local display that I am using.

I would really like to speed it up. I only want to capture about 15x15 pixels (always from the same place) but it takes almost 2 seconds each time. I am capturing to bmp format (I notice png takes even longer).

Is there any way to speed up? I am using KDE under linux - would it help if I used a more basic Desktop environment?

[anthony]

The screen capture used by x: appears to be only whole screen or window area limited.

Using the '[...]' crop method still captures a whole display.

I do not know if it accepts other options to limit the screen capture by area.



However their is a different technique that may be useful, capture directly from the hardware buffers.
These are raw notes, and may not be valid on all linux OS or hardware (it no longer works on my system, though it did a couple of years ago), but you get the idea.
You will need to have access to the frame buffer of course, and somehow specify the display size

Reading Linux Framebuffer with IM rgb:

Code: Select all

convert -depth 8 -size 800x600 rgb:/dev/fb/0'[0]' \
        -channel RGB -separate -swap 0,2 -combine \
        outfile.png

In case you can't tell, what that does, is take a screenshot of whatever's
currently displayed on your linux framebuffer (it works in console, too)
However it needs to swap the various channels to the right order IM expects.

This is for mine in particular, which is 800x600, 24bpp, BGR subpixels and
located at /dev/fb/0 (as opposed to /dev/fb0) in accordance with the devfs
structure...

I put the '[0]' subscript on there to keep it loading just the first page of
video memory, as there are two, for page-flipping and y-panning...

If you can think of a faster method, i'd love to hear it...

But in the mean time, you can look at this...

for i in `seq 0 n`; do
convert -depth 8 -size 800x600 rgb:/dev/fb/0'[0]' \
-channel RGB -separate -swap 0,2 -combine \
miff:-
done | convert miff:- animation.gif

I used a two-pass, because i can't figure out a way to do images in series
like that without unrolling the loop inside of the convert command line, and
that quickly becomes insanity...

Of course it's better for capture framerate if you do something more along the
lines of...

Code: Select all

# capture
for i in `seq 0 n`; do
  dd if=/dev/fb/0 of=outfile-`printf "%02d" $i`.rgb bs=1440000 count=1
done
# process
for i in `seq 0 n`; do
  convert -depth 8 -size 800x600 rgb:outfile-`printf "%02d" $i`.rgb
          -channel RGB -separate -swap 0,2 -combine \
          miff:-
done | convert miff:- outfile.gif
# clean up
rm *.rgb

The number 1440000 = Width X Height X 3

Depending on what effect you're trying to get, capturing faster could be good
or bad...

[victorlesk]

Thanks Anthony - before I get into all that,
I was using import -screen -window root because I was told it was the fastest. But would it be faster, assuming I had the ID of the window, just to import -window $WID? Especially in conjunction with minimizing other windows etc? What about using a black background and getting rid of desktop icons etc...

[victorlesk]

Hi Anthony. My monitor is allegedly 1920x1200, at least thats the size of the image that import -verbose -screen -window root temp.pnm gives me.

My fb device seems to be at /dev/fb0 (there is no /dev/fb directory). I'm running mandriva linux by the way.

So I tried...

Code: Select all

convert  -size 1920x1200 rgb:/dev/fb0'[0]' -channel RGB -separate -swap 0,2 -combine a.pnm

and it gave me the error

Code: Select all

convert: Unexpected end-of-file `/dev/fb0': Invalid argument.

It did the same when I used -depth 8 ( I want the images with default depth so I left this out by default.

Any ideas?

Thank you very much for your help so far.

Victor

[victorlesk]

Just a bit more info from my graphics settings - my monitor is 24bpp, 1920x1200, "translucency composite extension enabled", using a hardware accelerated mouse cursor and graphics card is "NVIDIA GeForceFX and Later"

[anthony]

Yes it looks like the modern linux no longer provides 'dev' file access to the frame buffers ;-(


As for using a window ID, it should be faster, particularly for very small windows compare to the total screen area.
All I can suggest is --- try it!

Of course let us know what happens.

[victorlesk]

Hi Anthony.. I just tried using -window 0x.... rather than -window root -screen. It takes exactly the same amount of time.. even though the window is only about half the size of the screen.

Is it worth considering installing an old version of linux which allows direct access to the fb?

There must be a way of doing it in "modern" linux.. can I address the memory directly somehow - it's the same bit of screen I want to capture repeatedly.

Or any other ideas..? I am pretty desperate.

I can't get my head round the fact that a machine that takes a fraction of a second to do billions of calculations, takes almost two seconds to read a lousy patch of its own screen.

Anyway, thanks again.

Victor

[victorlesk]

Something strange.. I installed the fbset package and showed my framebuffer settings with

Code: Select all

/usr/sbin/fbset -v -s

And it gave

Code: Select all

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "800x600-75"
    # D: 48.001 MHz, H: 46.876 kHz, V: 75.121 Hz
    geometry 800 600 800 600 16
    timings 20833 96 32 16 4 96 4
    rgba 5/11,6/5,5/0,0/0
endmode

Seems to suggest that my frame buffer geometry is 800x600. (This would explain why it reached end of file error when it tried to parse it as 1920x1200).
Moreover my /etc/fb.modes file doesn't even have any entries for 1920x1200.. the biggest mode it knows about is 1600x1200.

However the screen I am looking at *is* 1920x1200, it is obviously high res. So maybe my comp is not using the framebuffer!

I would love to understand what is going on!?

[victorlesk]

I have an nvidia graphics card and noticed the devices /dev/nvidia0 and /dev/nvidiactl exist, so I tried using these as the framebuffer to read from instead of /dev/fb0. No good..

Code: Select all

localhost $ fbgrab -d /dev/fb0 a.png
Converting image from 16
Now writing PNG file 

works, but the png is size 800x600 and garbage.

Code: Select all

 
localhost $ ls /dev/nvidia0
/dev/nvidia0
localhost $ fbgrab -d /dev/nvidia0 a.png
Error: Couldn't open /dev/nvidia0. 

[anthony]

There must be a way of doing it in "modern" linux.. can I address the memory directly somehow - it's the same bit of screen I want to capture repeatedly.

I would be more surprised if there wasn't. However I did not develop that technique, just squirrelled it away, but I figured it is probably a lot faster than asking the X server to do essentially the same thing via a network or socket connection.

Note that for many devices you may need superuser (root) permissions to access.

Hmmm.. the frame buffer may also be only used for 'console' type displays. Try running it on a console
Press Ctrl-Alt-F2 for example. To go back to the graphical display use Alt-F1 or Alt-F7 depending on your linux.


Looks as if the frame buffer disappeared with the 2.2 linux kernal The FrameBuffer HOWTO
http://en.tldp.org/HOWTO/Framebuffer-HOWTO.html
is dated 2000! and all utilities are from 1999. Looks like a dead end -- sorry.

The only modern information I found (this year and mentions 2.6 kernels) is
http://www.directfb.org/
But better information is on the wiki
http://www.directfb.org/wiki/index.php/Main_Page
On my system I found that 'directfb' was already installed but the framebuffer is not active.
I have not figured out how to activate the frame buffer (under fedora).
Closest I have is for gentoo kernel
http://www.linuxforums.org/forum/linux- ... t-1-a.html

[victorlesk]

That looks a little hard for me - I won't go down that route unless I have to. Thanks though.

I switched to an X command I discovered called xwd. It has sped things up considerably - cut down the time by approaching a factor of 3. That is probably enough although more would be appreciated..

The command I am using is
xwd -id $mywin_id | convert xwd:- -crop ...

The main improvement would be if the cropping could be done by xwd itself..

Thanks for your help anyway, I certainly learned something..