The only way I've done this is illustracted in the
visad.python.JPythonMethods.find() method that returns an integer array
of sampling indecies where the condition specified is met. For example:
int k = find(x, "gt", y)
Although it uses a visad Data subtract between the two Data's - which
takes care of any resampling needed, it then loops through that to
determine if the "condition" is met...so it's probably not going to help
you too much.
Regarding direct manipulations: it makes sense that the fewer pixels
that need to be re-drawn on the screen (such as when the scene is
smaller) the faster it will happen. In the old AWT days (which of
course we still use!) we would redraw only a portion of the 'background
image' when we moved something along on top of it. Someone else will
have to comment on what goes on in the Java3D world, though.
Kevin Manross wrote:
I am trying to optimize my code a bit. I have two FlatFields of the
same type (range->height) which produce two curves on the same display.
(Please see the right panel of:
I want to obtain all the ranges where the smooth curve lies below the
jagged curve. Currently, I am looping through the range points,
obtaining the values for each curve (smooth, jagged) at each point and
determine which is greater (saving those range points where the jagged
curve is greater than the smooth curve), and moving on to the next range
This works sufficiently, but 1) depending on the resolution I want (low
= 400, high = 1600) along the range, I am making that many comparisons
each time I move the red line on the left panel. 2) To calculate for
the entire circle on the left panel (720 red lines), that means I am
making between 288,000 and 1,152,000 comparisons. On my machine (1.2
GHz CPU, 1 Gb RAM) this takes about 40 seconds to do.
Is there a better way to find the intersection of two FlatFields?
On another performance topic, I have noticed that the smaller I shrink
my VisAD displays, the more responsive the DirectManipulationRenderers
are, and vice versa. I believe this is a somewhat common behavior that
deals with rendering as I have seen similar retardation with expanding
an .mpg or video game. Is this slowness vs. size tradeoff just
something to live with, or is there a way that I can speed things up?
Many thanks to those who have responded to my questions. I keep hoping
that I will become proficient enough to return the favor. ;-)
University of Wisconsin-Madison