Skip to main content

GRIN, z-order and redisplay

No replies
billf
Offline
Joined: 2004-02-13

Hi everyone,

We just made a fix to GRIN for an interesting little problem. I thought it might be relevant to more people than the followers of the putback alias, so I'm re-sending the putback message here...

When the GRIN scene changes by having the draw order of features
change, this changes the Z-order of any overlapping features. The
animation framework's change detection algorithm didn't take this
into account, so if features changed their z-order and didn't change
position or something else, they wouldn't be re-drawn. A simple
show that reproduces the problem is included with issue 215. It can
be run with grinview to show the problem.

To fix it, we track the sequence of drawing operations, as captured by
DrawRecords. If two features are drawn in a different order than they
were in the previous frame, we make sure the entire extent of one of them
is added to the damaged area(s), and thus redrawn. We don't try to tell
if they're overlapping or not.

This could theoretically cause slower drawing in the case where the draw
order changes in a way that would have no visible effect. However, we
don't think this happens often. The draw order can change when you switch
to a new segment, or change an assembly, or change the visible parts
of a group from scripting. In order to trigger a repaint, the order would
have to be different. In a survey of about ten shows, we didn't find a single
one where the order was unintentionally different.

Just in case, we do emit a debug message (when Debug.LEVEL >= 2) if a repaint
happens because of a drawing order change. It is:

NOTE: An area of the screen is being re-drawn due to a change in z-order.
If this is unexpected, then you may get more efficient drawing if you
re-structure your show to have a consistent ordering of the features.
See also https://hdcookbook.dev.java.net/issues/show_bug.cgi?id=215 .
This warning will not repeat.

If someone does unintentionally change the z-order (or drawing order) of
non-overlapping components, the results aren't too bad: just slightly
less efficient drawing. And, hopefully, this debug message will help out
anyone who does that, so they can make the show more efficient.

The performance impact of this extra draw-order bookkeeping should be pretty
minor. We were able to piggy-back on two loops that were already there.

By the way, this putback also includes a little fix to GrinView and the
bookmenu's grinview target. These were discovered during testing.

Code reviewed by Chihiro. Thanks, Chihiro! And thanks for pointing out
the problem, Phil!