| Backing store issue [message #47993] |
Mon, 27 March 2006 10:56  |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
I'm running IDL 6.2 on a SUN Blade 2000 running Solaris 8.0
I'm having a weird backing store problem. I have an application in
which I sometimes display very large images (eg 23123 x 3193 pixels).
What I do is create a scrolled draw widget of the same size as the image
and tv the image into that window. Then, I get to scroll around the
image very rapidly without having to issue any commands to redraw the
parts that become visible. It seems this should work fine as long as
the video card has enough memory.
However, the behavoir I am seeing seems as though IDL thinks the video
card has enough memory to handle the requests, when it really doesn't.
Is there any way to check for this?
By default, I use RETAIN=2, so that IDL is doing the redrawing for me
rather than the window manager (as this is usually less prone to problems).
I sometimes issue an explicit redraw command to redraw the entire image,
when I have changed the stretch limits or something other display
property of the image.
Under a certain size image, everything works fine. Unfortunately, when
the images get to be larger than a certain size, the redrawing on
scrolling often gives me garbage. There's got to be some tie-in with
the graphics card, but I think there may also be a tie-in with IDL,
since I'm using RETAIN=2.
Symptoms:
RETAIN=0, initial visible portion draws correctly, scrolling just shows
black everywhere else. If I scroll back to a place that was drawn fine
before, it will be black. Doing an explicit redraw will redraw the
visible portion. All this is as expected since I am not generating
expose events.
RETAIN=1, initial visible portion draws correctly, scrolling shows
black everywhere else. If I scroll back to a place that was drawn fine
before, it will still look fine. Doing an explicit redraw will redraw
the currently visible portion. Any portion that was visible during any
redraw operation seems to stick around in the backing store, everywhere
else is black.
RETAIN=2, initial visible portion looks like garbage. Scrolling
usually shows garbage. If you scroll slowly enough vertically (either
up or down), the part of the image that scrolls into view will look OK.
Scrolling horizontally will produce garbage regardless of the
scrolling speed.
If I am running on the SUN, but displaying on my Windows laptop,
everything works fine regardless of image size.
vedeo card on SUN Workstation: Sun XVR-1200
video card on my Windows box: NVIDIA GeForce4 4200 Go (Dell Mobile)
Any advice on how to figure out what's going on appreciated.
Thanks.
-Jonathan
|
|
|
|
| Re: Backing store issue [message #48108 is a reply to message #47993] |
Tue, 28 March 2006 11:31  |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
On Tue, 28 Mar 2006 12:24:22 -0600, Kenneth Bowman wrote:
> In article <pan.2006.03.28.18.03.44.500000@rsinc.com>,
> Karl Schultz <k____schultz@rsinc.com> wrote:
>
>> Aside from the ENVI stuff Liam mentioned, you also might want to take a
>> look at Object Graphics and the IDLgrImage object. We improved IDLgrImage
>> to use textures for storing/rendering images which really works better on
>> modern graphics cards. In IDL 6.2, we added LOD support and facilities
>> for handling huge images with tiling.
>
> LOD = Length of Day?
>
Sorry about that. Level of Detail. If you "zoom out" on a very large
image so that you have the entire image in the viewport, you can supply
IDLgrImage with downsampled image tiles. It is a little bit like texture
mip-mapping.
|
|
|
|
| Re: Backing store issue [message #48111 is a reply to message #47993] |
Tue, 28 March 2006 10:45 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Kenneth Bowman wrote:
> In article <pan.2006.03.28.18.03.44.500000@rsinc.com>,
> Karl Schultz <k____schultz@rsinc.com> wrote:
>
>
>> Aside from the ENVI stuff Liam mentioned, you also might want to take a
>> look at Object Graphics and the IDLgrImage object. We improved IDLgrImage
>> to use textures for storing/rendering images which really works better on
>> modern graphics cards. In IDL 6.2, we added LOD support and facilities
>> for handling huge images with tiling.
>
>
> LOD = Length of Day?
Lots Of Dots?
A huge image will have lots and lots of dots so maybe LALOD support is required.
ehem.
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
|
|
|
|
| Re: Backing store issue [message #48112 is a reply to message #47993] |
Tue, 28 March 2006 10:24 |
K. Bowman
Messages: 330
Registered: May 2000
|
Senior Member |
|
|
In article <pan.2006.03.28.18.03.44.500000@rsinc.com>,
Karl Schultz <k____schultz@rsinc.com> wrote:
> Aside from the ENVI stuff Liam mentioned, you also might want to take a
> look at Object Graphics and the IDLgrImage object. We improved IDLgrImage
> to use textures for storing/rendering images which really works better on
> modern graphics cards. In IDL 6.2, we added LOD support and facilities
> for handling huge images with tiling.
LOD = Length of Day?
Ken Bowman
|
|
|
|
| Re: Backing store issue [message #48113 is a reply to message #47993] |
Tue, 28 March 2006 10:03 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
OK, I was just trying to help by trying to isolate the problem to the X
server or to IDL.
It is probably your window manager that believes no one wants to see a
window bigger than the root window and so prevents clients from creating
large windows. There's probably a setting for the wm that controls this.
Aside from that, I think I agree with you guys that the copy is failing in
the X server. This guess is supported somewhat by the observation that
vertical scrolls work better than horizontal ones. Vertical rows of
pixels are much easier to move around in video memory because they are
naturally more contiguous than a few horizontal columns. The server is
probably failing to find a block of the right size in vid memory to
perform the blit, and then quietly fails. It is too bad we don't see a
protocol error for this.
Aside from the ENVI stuff Liam mentioned, you also might want to take a
look at Object Graphics and the IDLgrImage object. We improved IDLgrImage
to use textures for storing/rendering images which really works better on
modern graphics cards. In IDL 6.2, we added LOD support and facilities
for handling huge images with tiling.
Karl
On Mon, 27 Mar 2006 17:44:21 -0500, Jonathan Joseph wrote:
>
> The code you've given doesn't have the desired effect on the Sun because
> it will limit the size of the window it creates to the size of the
> screen. So it's not a valid test.
>
> If I give my program a large enough image to open though, I get the same
> kind of error you are probably seeing.
>
> % WIDGET_CONTROL: Unable to create X windows pixmap (BadAlloc
> (insufficient resources for operation)).
>
> The program then runs, but with no backing store. This is probably what
> it should do in the case where I am seeing garbage.
>
> It seems only to be in a grey area inbetween where it will create the
> pixmap, but the pixmap will end up with some garbage in it.
>
> I think David has pretty well assessed the situation.
>
> -Jonathan
>
> Karl Schultz wrote:
>
>> On Mon, 27 Mar 2006 16:20:51 -0500, Jonathan Joseph wrote:
>>
>> What happens if you try:
>>
>> device, true=24, decomposed=1
>> window, xsize=23000, ysize=3000, retain=2 tv, bindgen(3,23000, 3000),
>> /true
>>
>> ?
>>
>> On my linux box with nvidia FX 500, the large window repairs
>> automatically, as it should, when I drag it around or drag other things
>> on top of it.
>>
>> If I make the window a LOT larger, say 23000 x 23000, I get a nice
>> error from IDL saying that there are not enough resources to allocate a
>> pixmap, which is what IDL uses for backing store when RETAIN=2.
>>
>> It would be interesting to know how the above code behaves on your
>> machine.
>>
>> Karl
>>
>>
|
|
|
|
| Re: Backing store issue [message #48114 is a reply to message #47993] |
Tue, 28 March 2006 08:59 |
liamgumley
Messages: 74
Registered: June 2005
|
Member |
|
|
Jonathan,
Have you looked at the ENVI display paradigm? If not, you may want to
install the ENVI demo to see how it handles large images.
Liam.
Practical IDL Programming
http://www.gumley.com/
Jonathan Joseph wrote:
> The code you've given doesn't have the desired effect on the Sun because
> it will limit the size of the window it creates to the size of the
> screen. So it's not a valid test.
>
> If I give my program a large enough image to open though, I get the same
> kind of error you are probably seeing.
>
> % WIDGET_CONTROL: Unable to create X windows pixmap (BadAlloc
> (insufficient resources for operation)).
>
> The program then runs, but with no backing store. This is probably what
> it should do in the case where I am seeing garbage.
>
> It seems only to be in a grey area inbetween where it will create the
> pixmap, but the pixmap will end up with some garbage in it.
>
> I think David has pretty well assessed the situation.
>
> -Jonathan
|
|
|
|
| Re: Backing store issue [message #48132 is a reply to message #47993] |
Mon, 27 March 2006 14:44 |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
The code you've given doesn't have the desired effect on the Sun because
it will limit the size of the window it creates to the size of the
screen. So it's not a valid test.
If I give my program a large enough image to open though, I get the same
kind of error you are probably seeing.
% WIDGET_CONTROL: Unable to create X windows pixmap (BadAlloc
(insufficient resources for operation)).
The program then runs, but with no backing store. This is probably what
it should do in the case where I am seeing garbage.
It seems only to be in a grey area inbetween where it will create the
pixmap, but the pixmap will end up with some garbage in it.
I think David has pretty well assessed the situation.
-Jonathan
Karl Schultz wrote:
> On Mon, 27 Mar 2006 16:20:51 -0500, Jonathan Joseph wrote:
>
> What happens if you try:
>
> device, true=24, decomposed=1
> window, xsize=23000, ysize=3000, retain=2
> tv, bindgen(3,23000, 3000), /true
>
> ?
>
> On my linux box with nvidia FX 500, the large window repairs
> automatically, as it should, when I drag it around or drag other things
> on top of it.
>
> If I make the window a LOT larger, say 23000 x 23000, I get a nice error
> from IDL saying that there are not enough resources to allocate a pixmap,
> which is what IDL uses for backing store when RETAIN=2.
>
> It would be interesting to know how the above code behaves on your machine.
>
> Karl
>
>
|
|
|
|
| Re: Backing store issue [message #48133 is a reply to message #47993] |
Mon, 27 March 2006 13:48 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
On Mon, 27 Mar 2006 16:20:51 -0500, Jonathan Joseph wrote:
What happens if you try:
device, true=24, decomposed=1
window, xsize=23000, ysize=3000, retain=2
tv, bindgen(3,23000, 3000), /true
?
On my linux box with nvidia FX 500, the large window repairs
automatically, as it should, when I drag it around or drag other things
on top of it.
If I make the window a LOT larger, say 23000 x 23000, I get a nice error
from IDL saying that there are not enough resources to allocate a pixmap,
which is what IDL uses for backing store when RETAIN=2.
It would be interesting to know how the above code behaves on your machine.
Karl
> So be it.
>
> Thanks for your insights David.
>
> -Jonathan
>
> David Fanning wrote:
>
>> I'm not saying these are perfect solutions. I'm just saying you are
>> creating one BIG window! It doesn't surprise me (given my experience
>> with pixmaps and backing store) you are having problems. I would be
>> more surprised if you weren't having problems. :-)
>>
>> Cheers,
>>
>> David
>>
>> P.S. You could always write machine-specific code and let the guys on
>> the SUN get by with sluggish graphic performance. They might even be
>> used to it. :-)
>>
|
|
|
|
| Re: Backing store issue [message #48134 is a reply to message #47993] |
Mon, 27 March 2006 13:20 |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
So be it.
Thanks for your insights David.
-Jonathan
David Fanning wrote:
> I'm not saying these are perfect solutions. I'm
> just saying you are creating one BIG window! It doesn't
> surprise me (given my experience with pixmaps and
> backing store) you are having problems. I would be
> more surprised if you weren't having problems. :-)
>
> Cheers,
>
> David
>
> P.S. You could always write machine-specific code
> and let the guys on the SUN get by with sluggish
> graphic performance. They might even be used to it. :-)
>
|
|
|
|
| Re: Backing store issue [message #48135 is a reply to message #47993] |
Mon, 27 March 2006 12:58 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jonathan Joseph writes:
> I just realized that,
>
> Even if I code it the way you say, I will still see clunkiness if I grab
> the slider and slide it fast - or if I scroll by holding my mouse button
> down in the scroll bar but not on the thumb. Then it will go a screen
> at at time, and there won't be anything to DEVICE COPY.
>
> Using retain=2 (or 1) gives me fast scrolling under all circumstances
> (when it works as advertised).
I'm not saying these are perfect solutions. I'm
just saying you are creating one BIG window! It doesn't
surprise me (given my experience with pixmaps and
backing store) you are having problems. I would be
more surprised if you weren't having problems. :-)
Cheers,
David
P.S. You could always write machine-specific code
and let the guys on the SUN get by with sluggish
graphic performance. They might even be used to it. :-)
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Backing store issue [message #48137 is a reply to message #47993] |
Mon, 27 March 2006 12:40 |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
I just realized that,
Even if I code it the way you say, I will still see clunkiness if I grab
the slider and slide it fast - or if I scroll by holding my mouse button
down in the scroll bar but not on the thumb. Then it will go a screen
at at time, and there won't be anything to DEVICE COPY.
Using retain=2 (or 1) gives me fast scrolling under all circumstances
(when it works as advertised).
-J
David Fanning wrote:
>
> When scrolling, usually only a *few* rows or columns need
> to be drawn. Most of what you need is already on the display,
> it just has to be moved with DEVICE COPY. Surely, *this*
> is fast enough! :-)
>
> Cheers,
>
> David
|
|
|
|
| Re: Backing store issue [message #48138 is a reply to message #47993] |
Mon, 27 March 2006 12:36 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jonathan Joseph writes:
> I was afraid you were going to write something like that and expose me
> for the hack-programmer that I am.
Not up to speed with DEVICE COPY!? What do you use when
you need smoke and mirrors? :-)
> I suppose I could (and will have to) do as you say, but I still believe
> that I shouldn't have to write this code when RSI claims to have written
> it for me. I think IDL should be querying the video card and if it
> doesn't have enough memory for the request, then IDL should either use
> some other method or at least give me an error message - not just give
> me garbage in the window.
>
> If I program it myself, maybe I won't get it right. Maybe the
> programmers are RSI didn't get it right, which is why works only when I
> scroll a few lines a time (and only in the vertical direction), and not
> when I scroll faster.
Having confronted the issue of backing store memory MANY
times, I'm pretty much convinced that no sane programmer
could possibly get it right. Every OS, every graphics card,
seems to do it differently. I have a program that supposedly
checks to see how much pixmap memory is available, but it
returns different results depending on the phase of the
moon and what I ate for breakfast. I always divide the result
by two, just to be on the safe side, and even that sometimes
doesn't work. (With some cards, the *shape* of the window
matters more than the *size* of the window. Go figure...)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Backing store issue [message #48139 is a reply to message #47993] |
Mon, 27 March 2006 12:24 |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
David,
I was afraid you were going to write something like that and expose me
for the hack-programmer that I am.
I suppose I could (and will have to) do as you say, but I still believe
that I shouldn't have to write this code when RSI claims to have written
it for me. I think IDL should be querying the video card and if it
doesn't have enough memory for the request, then IDL should either use
some other method or at least give me an error message - not just give
me garbage in the window.
If I program it myself, maybe I won't get it right. Maybe the
programmers are RSI didn't get it right, which is why works only when I
scroll a few lines a time (and only in the vertical direction), and not
when I scroll faster.
-J
David Fanning wrote:
>
> When scrolling, usually only a *few* rows or columns need
> to be drawn. Most of what you need is already on the display,
> it just has to be moved with DEVICE COPY. Surely, *this*
> is fast enough! :-)
>
> Cheers,
>
> David
|
|
|
|
| Re: Backing store issue [message #48140 is a reply to message #47993] |
Mon, 27 March 2006 11:41 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jonathan Joseph writes:
> Technology-schmology. It's speed I'm interested in. I use app_scroll
> in another application that will view the same images without any
> problems, and the scrolling is *MUCH* slower if you have any reasonably
> sized viewing window - like 1000 x 1000 pixels.
When scrolling, usually only a *few* rows or columns need
to be drawn. Most of what you need is already on the display,
it just has to be moved with DEVICE COPY. Surely, *this*
is fast enough! :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Backing store issue [message #48141 is a reply to message #47993] |
Mon, 27 March 2006 11:37 |
Jonathan Joseph
Messages: 69
Registered: September 1998
|
Member |
|
|
Technology-schmology. It's speed I'm interested in. I use app_scroll
in another application that will view the same images without any
problems, and the scrolling is *MUCH* slower if you have any reasonably
sized viewing window - like 1000 x 1000 pixels.
Sure app_scroll may be more reliable, but it doesn't make me happier.
And when I'm paying big $$ for applications like IDL and pricey video
cards, I expect them to work as advertized. OK, so I'm not paying - but
somebody is :-)
-Jonathan
David Fanning wrote:
> Jonathan Joseph writes:
>
>
>> I'm having a weird backing store problem. I have an application in
>> which I sometimes display very large images (eg 23123 x 3193 pixels).
>
>
> Uh, if you don't mind my saying so, you put too
> much faith in technology. :-)
>
> I'd use the APP_SCROLL, and redraw when something comes
> into view. It will be SO much more reliable!
>
> Cheers,
>
> David
|
|
|
|
| Re: Backing store issue [message #48142 is a reply to message #47993] |
Mon, 27 March 2006 11:23 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jonathan Joseph writes:
> I'm having a weird backing store problem. I have an application in
> which I sometimes display very large images (eg 23123 x 3193 pixels).
Uh, if you don't mind my saying so, you put too
much faith in technology. :-)
I'd use the APP_SCROLL, and redraw when something comes
into view. It will be SO much more reliable!
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
