Re: IDL 6.2 IDLgrImage SUB_RECT and TILING [message #46280 is a reply to message #45970] |
Thu, 10 November 2005 08:35  |
Steven Houston
Messages: 5 Registered: November 2005
|
Junior Member |
|
|
Hi,
What you are seeing is correct. When you set the SUB_RECT property the
image is resized to only include the SubRect area. In your diagram if
you set the SUB_RECT to cover tile 3, the image is resized and all the
tiles outside tile 3 are discarded.
If you wish to keep the other tiles but prevent them being visible in
case your user pans you could look at using CLIP_PLANES on the
IDLgrModel containing the image.
Regards,
Steve.
Robbie Barnett wrote:
> G'Day,
>
> Has anyone been experimenting with the new properties available in
> IDLgrImage?
>
> I've been using the new image tiling features in IDL 6.2 for generating
> fast and memory efficent slicing and animations. To render an animation
> I store all frames from an animation sequence side-by-side in a single
> image.
> There is an (semi) explanatory diagram at
> http://www.zipworld.com.au/~retsil/idl/news/slicing.png
>
> I use the TILING keyword for extra efficiency. This is for when I only
> want to compute frames as they are rendered and/or only cache frames
> when graphics memory is available. In fact, this allows me to render
> animation or slicing sequences which are larger than what can fit into
> graphics memory.
>
> When I want to animate, I move the current transfer matrix (CTM) so it
> displays each frame in sequence. However, I would prefer to use the
> SUB_RECT
> property to crop the image display (a neat way to prevent the user
> using a pan/zoom
> tool to view adjacent frames), however, SUB_RECT does not behave in the
> way which I would expect. Instead the SUB_RECT keyword deletes all of
> my
> cached tiles each time the property is changed. At the same time I get
> floating point errors from the IDLgrWindow::Draw method.
>
> Given the lack of documentation on the SUB_RECT property, what do you
> think?
> Bug or feature?
>
> (Note: This has been lodged as an RSI Incident #197686)
>
|
|
|