kelley@open.dal.ca (Dan Kelley) (05/21/91)
I've used Guide and Gxv to create an xview interface. These are great
programs: a few hours of tinkering gave me a functional interface.
However, I'm reluctant to do the next step -- adding my own code to
the Guide-generated callback functions -- because the application
starts out by calling my repaint function SIX times! My application
is pretty slow, even if no actual drawing is taking place, so this
will totally kill performance.
I'm not an X expert (that's why I'm using Guide, after all), so I
wonder whether anybody out there can suggest a way around this
performance killer. For example, is there some kind of countdown flag
I can monitor, so I can do the repaint only the last time it's
requested?
Below I've pasted the code that Guide wrote for me:
/*
* Repaint callback function for `canvas1'.
*/
void
repaint_gri(canvas, paint_window, display, xid, rects)
Canvas canvas;
Xv_window paint_window;
Display *display;
Window xid;
Xv_xrectlist *rects;
{
fputs("grixv: repaint_gri\n", stderr);
}
--
Dan Kelley, Oceanography Department | kelley@cs.dal.ca
Dalhousie University | {uunet watmath}!dalcs!kelley
Halifax, Nova Scotia, CANADA, B3H 4J1 | (902) 494-1694
jcb@NCD.COM (Jim Becker) (05/22/91)
kelley@open.dal.ca (Dan Kelley) writes:
However, I'm reluctant to do the next step -- adding my own code to
the Guide-generated callback functions -- because the application
starts out by calling my repaint function SIX times!
this is because of the number of times that XView internally resizes
the windows it creates. what it does originally is create a window
size 100x100, then it gets torqued to different sizes multiple times.
Eventually when things settle down all the pending resize related
events are processed.
I'm not an X expert (that's why I'm using Guide, after all), so I
wonder whether anybody out there can suggest a way around this
performance killer. For example, is there some kind of countdown flag
I can monitor, so I can do the repaint only the last time it's
requested?
yes, this is a potential performance problem. however you should not
*assume* there will be five dummy calls before the final call. for the
next release of XView this problem has been lessened, so you will
*not* get six calls to repaint.
one way to flush these events is to look into the queued events coming
off the connection, and don't do a repaint unless there are no more
Expose events for the window representing your canvas. this can be
done by looking at the XEvents off of:
struct _XSQEvent *head
display->head
and scanning for Expose events with matching window XID.
sorry, don't have code handy to do this - but it's simple enough.
(albeit not truely legal in the X world.)
You can also use XPeekIfEvent() with a False returning predicate that
has the side effect of setting a flag according to the exposure event
presence/absence (which is a legal method, but slow).
--
Dan Kelley, Oceanography Department | kelley@cs.dal.ca
-Jim Becker (eX-XView group member)
--
--
-Jim Becker / jcb@ncd.com / Network Computing Devices, Inc. (NCD)