| Re: Testers needed for TV benchmark [message #26129] |
Wed, 08 August 2001 14:58  |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
"Pavel A. Romashkin" wrote:
>
> I was trying this as JD sent this post. I must admit that there was no
> speed increase, to my dismay.
Duh! It helps when you place the timer in the right place. I was timing
everything, including preloading. Thank you, Liam. Of course, the
correct output for preloaded pixmap windows is
TV-Device Copy Test: Array Size: 512 0.71153700 seconds
=> Frames/sec: 70.270414 Frame time: 0.014230740
Video Xfer rate: 55262902. bytes/sec
TV Direct Test: Array Size: 512 3.1362751 seconds
=> Frames/sec: 15.942479 Frame time: 0.062725501
Video Xfer rate: 12537676. bytes/sec
Sorry.
Pavel
|
|
|
|
| Re: Testers needed for TV benchmark [message #26131 is a reply to message #26129] |
Wed, 08 August 2001 14:47  |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
The true color version of my test procedure gives slightly lower display
and animation rates, at least on my system:
PRO TEST_TRUE, DELAY=DELAY
;- Load the image
filename = filepath('rose.jpg', subdir='examples/data')
read_jpeg, filename, image
xsize = 3 * 227
ysize = 3 * 149
image = rebin(image, 3, xsize, ysize)
;- Set initial parameters
nframes = 20
if (n_elements(delay) eq 0) then delay = 0.05
;- Display image in pixmap windows
t0 = systime(1)
for frame = 0, nframes - 1 do begin
window, frame, /pixmap, xsize=xsize, ysize=ysize
tv, shift(image, 0, 10 * frame, 0), true=1
endfor
t1 = systime(1)
print, 'Display rate (frames/sec) = ', $
float(nframes) / (t1 - t0)
;- Animate the images
window, /free, xsize=xsize, ysize=ysize
t0 = systime(1)
for frame = 0, nframes - 1 do begin
device, copy=[0, 0, xsize, ysize, 0, 0, frame]
wait, delay
endfor
t1 = systime(1)
print, 'Animation rate (frames/sec) = ', $
float(nframes) / (t1 - t0)
END
IDL> test_true
Display rate (frames/sec) = 3.3394557
Animation rate (frames/sec) = 15.491868
IDL> test_true, delay=0.0
Display rate (frames/sec) = 3.3344448
Animation rate (frames/sec) = 45.351475
Cheers,
Liam.
Practical IDL Programming
http://www.gumley.com/
|
|
|
|
| Re: Testers needed for TV benchmark [message #26132 is a reply to message #26131] |
Wed, 08 August 2001 14:33 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
"Bill B." wrote:
> "Liam E. Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:<3B7183C6.4D1A3622@ssec.wisc.edu>...
>
>> To obtain the best frame rate for animations, first you should display
>> all the images in a pixmap window, and *then* use DEVICE, COPY to copy
>> each image to a visible graphics window. I'm willing to bet you'll get
>> frame rates better than 10 frames/sec using this method.
>>
>
> Hi Liam,
>
> If you look at my benchmark, that is the 1st of the two tests being
> executed:
>
> <snip>
>
> FOR I = 0, 49 DO BEGIN
> WSET, pixmap0_id
> TV, data, true = 3
> WSET, pixmap1_id
> DEVICE, COPY = [0, 0, sz-1, sz-1, 0, 0, pixmap0_id]
> ENDFOR
>
> <snip>
>
> Also, the results I posted show no difference between the technique
> that you describe and just TVing directly to the visible window. Ten
> fps at 512*512 would be great but I see no indication that I can
> achieve that on a PC. BTW, this benchmarking is in preparation for
> what will be the SW end of a generic (any format) video frame grabber.
> Could you verify if the snippet above is what you had in mind?
Bill,
The rate at which you can *display* images is different than the rate at
which you can *animate* images. To demonstrate, the following procedure
uses two loops. The first loop displays a sequence of images in pixmap
windows. The second loop copies images from the pixmap windows to a
visible graphics window:
PRO TEST, DELAY=DELAY
;- Set initial parameters
xsize = 512
ysize = 512
nframes = 20
image = dist(512)
if (n_elements(delay) eq 0) then delay = 0.05
;- Display image in pixmap windows
t0 = systime(1)
for frame = 0, nframes - 1 do begin
window, frame, /pixmap, xsize=xsize, ysize=ysize
tvscl, shift(image, 10 * frame)
endfor
t1 = systime(1)
print, 'Display rate (frames/sec) = ', $
float(nframes) / (t1 - t0)
;- Animate the images
window, /free, xsize=xsize, ysize=ysize
t0 = systime(1)
for frame = 0, nframes - 1 do begin
device, copy=[0, 0, xsize, ysize, 0, 0, frame]
wait, delay
endfor
t1 = systime(1)
print, 'Animation rate (frames/sec) = ', $
float(nframes) / (t1 - t0)
END
If the DELAY keyword is not set, the default interval between each frame
is 0.05 seconds. Set DELAY=0.0 to see how fast your system can copy
images from pixmap windows to a visible window. On my PC running IDL
5.3:
IDL> test
Display rate (frames/sec) = 4.0265754
Animation rate (frames/sec) = 15.974441
IDL> test, delay=0.0
Display rate (frames/sec) = 4.0104271
Animation rate (frames/sec) = 56.980046
To summarize, the rate at which you can display the images with TV or
TVSCL is much slower than the rate at which you can animate the images
using DEVICE, COPY=[...].
Cheers,
Liam.
Practical IDL Programming
http://www.gumley.com/
|
|
|
|
| Re: Testers needed for TV benchmark [message #26133 is a reply to message #26132] |
Wed, 08 August 2001 14:23 |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
JD Smith wrote:
>
> "Bill B." wrote:
>>
> I suspect Liam actually meant something more like:
>
> WSET, pixmap0_id
> TV, data, true = 3
> T0 = SYSTIME(1)
> FOR I = 0, 49 DO BEGIN
> WSET, pixmap1_id
> DEVICE, COPY = [0, 0, sz-1, sz-1, 0, 0, pixmap0_id]
> ENDFOR
>
> That is, preload your pixmap with the image. This will most certainly
> result in much higher frame rates, but incurring the expense of
> preloading.
I was trying this as JD sent this post. I must admit that there was no
speed increase, to my dismay.
Pavel
|
|
|
|
| Re: Testers needed for TV benchmark [message #26134 is a reply to message #26133] |
Wed, 08 August 2001 14:12 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
"Bill B." wrote:
>
> "Liam E. Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:<3B7183C6.4D1A3622@ssec.wisc.edu>...
>
>> To obtain the best frame rate for animations, first you should display
>> all the images in a pixmap window, and *then* use DEVICE, COPY to copy
>> each image to a visible graphics window. I'm willing to bet you'll get
>> frame rates better than 10 frames/sec using this method.
>>
>
> Hi Liam,
>
> If you look at my benchmark, that is the 1st of the two tests being
> executed:
>
> <snip>
>
> FOR I = 0, 49 DO BEGIN
> WSET, pixmap0_id
> TV, data, true = 3
> WSET, pixmap1_id
> DEVICE, COPY = [0, 0, sz-1, sz-1, 0, 0, pixmap0_id]
> ENDFOR
>
> <snip>
>
> Also, the results I posted show no difference between the technique
> that you describe and just TVing directly to the visible window. Ten
> fps at 512*512 would be great but I see no indication that I can
> achieve that on a PC. BTW, this benchmarking is in preparation for
> what will be the SW end of a generic (any format) video frame grabber.
> Could you verify if the snippet above is what you had in mind?
I suspect Liam actually meant something more like:
WSET, pixmap0_id
TV, data, true = 3
T0 = SYSTIME(1)
FOR I = 0, 49 DO BEGIN
WSET, pixmap1_id
DEVICE, COPY = [0, 0, sz-1, sz-1, 0, 0, pixmap0_id]
ENDFOR
That is, preload your pixmap with the image. This will most certainly
result in much higher frame rates, but incurring the expense of
preloading. This technique can be useful for animation if you have the
sequence of images to animate. Preload them all into their own pixmaps,
and then blitz through them.
For real, dynamic frame rate, this obviously won't do. An example might
be a filter being applied interactively, data streaming from a camera,
etc. Here I could only say that IDL isn't really designed to support
high frame rate streaming video. You might be able to accomplish
something via external DLM code which fills a pixmap buffer (presumably
much more rapidly than IDL can), and then let IDL retrieve data from
that pixmap, but otherwise I think you're stuck.
TV will work much faster (especially with some video hardware), if you
relax the need for TRUECOLOR. A single plane of 8-bit resolution data
run through a hardware colortable will draw much more rapidly. I got
frame rates for 512x512 images on the order of 13fps at 8 bit, on pretty
pokey hardware.
This brings up another interesting technique which has to do with
multiple draws to a given window -- a commonly enough performed
operation in IDL. If you, for instance, need to plot several different
data sets, overlay lines and annotation, while allowing the plot to be
interactively modified (e.g. a changing parameter), a vastly superior
solution to direct drawing is available as "double buffering". It's
quite simple. As in this example, you simply perform all your draw
operations to a pixmap, and then device,COPY= the resultant image over.
If you have multiple draw operations (unlike in Bill's case), this will
be noticeably faster. It will also be smoother, eliminating the
jerkiness you may have experienced with interactive plotting.
JD
|
|
|
|
|
|
| Re: Testers needed for TV benchmark [message #26137 is a reply to message #26135] |
Wed, 08 August 2001 13:55 |
billb
Messages: 5
Registered: August 2001
|
Junior Member |
|
|
"Liam E. Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:<3B7183C6.4D1A3622@ssec.wisc.edu>...
> To obtain the best frame rate for animations, first you should display
> all the images in a pixmap window, and *then* use DEVICE, COPY to copy
> each image to a visible graphics window. I'm willing to bet you'll get
> frame rates better than 10 frames/sec using this method.
>
Hi Liam,
If you look at my benchmark, that is the 1st of the two tests being
executed:
<snip>
FOR I = 0, 49 DO BEGIN
WSET, pixmap0_id
TV, data, true = 3
WSET, pixmap1_id
DEVICE, COPY = [0, 0, sz-1, sz-1, 0, 0, pixmap0_id]
ENDFOR
<snip>
Also, the results I posted show no difference between the technique
that you describe and just TVing directly to the visible window. Ten
fps at 512*512 would be great but I see no indication that I can
achieve that on a PC. BTW, this benchmarking is in preparation for
what will be the SW end of a generic (any format) video frame grabber.
Could you verify if the snippet above is what you had in mind?
Thanks a bunch,
Bill
|
|
|
|
|
|
| Re: Testers needed for TV benchmark [message #26215 is a reply to message #26129] |
Thu, 09 August 2001 08:42 |
karl_schultz
Messages: 13
Registered: August 2001
|
Junior Member |
|
|
I just want to point out something to look out for, since it is rather
counter-intuitive and a bit surprising. I discovered this on a Linux
system while trouble-shooting a performance problem.
X servers often implement pixmaps by storing them in unused
(off-screen) frame buffer memory under the assumption that the
performance of these pixmaps is better than the ones in system memory.
The idea is that blitting the pixmap to a window would be faster
since it is just a copy within a memory subsystem, rather than a
transfer from system memory to frame buffer memory.
Of course, once the unused frame buffer memory is exhausted,
additional pixmaps are stored in system memory.
The surprise is that, on some X servers, the off-screen pixmaps are
actually slower than the system memory pixmaps. I can't explain this,
other than to suspect an implementation problem or oversight in the X
server code.
You can detect this by caching a series of, say, 50 images in pixmaps,
as described in other posts in this thread. Then, measure the time it
takes to copy each one to a window. Or, just watch the animation. If
the first few seem slower, then this might be the problem.
One way to "fix" this is to create a set of dummy pixmaps not used in
the actual animation to "use up" the slow pixmaps. Then, the rest of
the pixmaps will all be the "fast" ones. Of course, this is all too
dependent on the X server, frame buffer memory size, desktop size, and
size of the pixmaps.
Even when the X server implementation is better, that is, the
off-screen pixmaps are faster, this can cause confusing benchmark
results since the copy times can vary in hard-to-describe ways.
Karl
"Pavel A. Romashkin" <pavel.romashkin@noaa.gov> wrote in message news:<3B71B610.DDB1A33A@noaa.gov>...
> "Pavel A. Romashkin" wrote:
>>
>> I was trying this as JD sent this post. I must admit that there was no
>> speed increase, to my dismay.
>
> Duh! It helps when you place the timer in the right place. I was timing
> everything, including preloading. Thank you, Liam. Of course, the
> correct output for preloaded pixmap windows is
>
> TV-Device Copy Test: Array Size: 512 0.71153700 seconds
> => Frames/sec: 70.270414 Frame time: 0.014230740
> Video Xfer rate: 55262902. bytes/sec
> TV Direct Test: Array Size: 512 3.1362751 seconds
> => Frames/sec: 15.942479 Frame time: 0.062725501
> Video Xfer rate: 12537676. bytes/sec
>
> Sorry.
> Pavel
|
|
|
|
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
