| Re: memory for pixmaps: big vs many [message #54597] |
Thu, 21 June 2007 15:12 |
Jim Pendleton, ITT Vi
Messages: 13
Registered: August 2006
|
Junior Member |
|
|
You may find it worth testing whether or not you even need
pixmaps since physical memory transfer to the card is generally
fast enough these days to display "appropriately sized" animations
smoothly, and will also generally provide you with significantly more
room to save frames, assuming you don't induce a paging condition.
That is, if you have an RGB image cube in memory (and it's not in
a paging condition) the following action (in Object Graphics notation)
oImage->SetProperty, $
Data = Reform(Frames[*, *, *, CurrentFrame])
oDrawWindow->Draw
can be comparable to pixmap display speed. On more modern
hardware and "reasonable" image sizes, you can often exceed the
refresh rate of the graphics card using this technique.
I haven't tested this theory with the TV command in Direct Graphics,
so your mileage may vary.
Alternatively, in Object Graphics you can pre-load a series of
IDLgrImage objects into models then use the IDLgrModel's SelectTarget
property to specify which to draw. The overhead here is that the ::Draw
method
must be called once on each image for it to be loaded into graphics memory,
making the initial display of each image sequence slow-ish; but subsequent
displays will be much faster. Unlike the physical memory option, though,
you'll be limited to the size of the graphics memory; If you exceed this
limit, then parts of the graphics memory may be sent back to physical
memory and the OS then has the option of (shudder) paging them off
to disk, which will destroy any performance gain you may have hoped
to get.
Jim P.
"Richard Clark" <rclark@hindmost.lpl.arizona.edu> wrote in message
news:f5ej1b$hgg$1@onion.ccit.arizona.edu...
> In using offscreen pixmaps to preload a sequence of images for smooth
> display in an animation you can run up against memory limitations in the
> graphics hardware.
>
> Two aproaches are to set up a very large pixmap that is
> xsize*total_images by ysize and store the images along the x length
> of the pixmap,
> or
> to set up total_images xsize by ysize pixmaps, one to an image.
>
> The latter aproach gives your OS and graphics hardware more of a chance
> to make use virtual memory. Works like a charm on my linux system while
> the big pixmap movie loop hits the graphics card memory limit.
>
> But a search through some discussion on the topic suggests that there
> will likely be some OS and/or graphics card specific differences in
> how well it works.
>
> Does anyone have experience with this on multiple platforms and could
> comment? For instance, any OS-wide generalizations that can be made,
> or is it hopelessly graphics card dependent?
>
> On a related note, the animation I'm interested in displaying is made
> up of b&w images. So using an 8 bit rather than 24 bit mode should
> make room for more images to be loaded in the card's memory.
>
> Does using an 8 bit mode make room for 3x, 4x, or 1x times as many
> images?
>
> Richard Clark
> rclark@lpl.arizona.edu
|
|
|
|
| Re: memory for pixmaps: big vs many [message #54598 is a reply to message #54597] |
Thu, 21 June 2007 14:05  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Richard Clark writes:
> In using offscreen pixmaps to preload a sequence of images for smooth
> display in an animation you can run up against memory limitations in the
> graphics hardware.
> Does anyone have experience with this on multiple platforms and could
> comment? For instance, any OS-wide generalizations that can be made,
> or is it hopelessly graphics card dependent?
Not only is it graphics card dependent, but in my
experience there is direct correlation between the
importance of the job and the number of pixmap problems
you run into. :-)
> On a related note, the animation I'm interested in displaying is made
> up of b&w images. So using an 8 bit rather than 24 bit mode should
> make room for more images to be loaded in the card's memory.
>
> Does using an 8 bit mode make room for 3x, 4x, or 1x times as many
> images?
I'm not aware that you can create pixmaps in anything other than
the default OS dependent flavor.
Sorry I don't have better information to convey. But I will
tell you about one little wrinkle I have used successfully
in my Catalyst Library. There pixmaps are simply draw widgets
in unmapped top-level base widgets. We did this to get around
the video ram problems you mention, but I can't remember now whether
this was strictly due to smaller windows, or because real windows
don't use pixmap memory in the same way that pixmaps do. In any
case, it worked and solved our problems.
The was one very nice bonus to creating pixmaps this way.
Whenever we wanted to see what was on a pixmap, all we had
to do was set its MAP property, and it immediately showed up
on the display. VERY handy for debugging purposes!
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
