Scott McMillan (scott++at++hf.ht.com)
Fri, 3 May 1996 12:28:04 -0400 (EDT)
Right now, I have two channels associated with the same pipe. The viewports
are set so that they do not overlap. In one channel, I display the logo, and
in the other I run draw the results of a dynamic simulation. I set the draw
traversal function as follows:
logo_chan->setTravFunc(PFTRAV_DRAW, drawLogoChannel);
which draws/pastes the RGB logo to the front and back buffers (is there a way
to do this straight to both buffers without using swapbuffers()?), but to
save CPU cycles, I disable the draw traversal in the logo's channel as
follows (done in the APP):
logo_chan->setTravMode(PFTRAV_DRAW, PFDRAW_OFF);
Whenever I get a PFUDEV_REDRAW event (again, in APP) I set the traversal mode
to PFDRAW_ON, and at the end of drawLogoChannel() I set the traversal mode to
PFDRAW_OFF. When uniprocessing, this works the way I expect by calling
drawLogoChannel once for every redraw event. When I fork the DRAW, turning
the traversal off does not seem to get communicated back to the APP so that
once the APP turns it on, drawLogoChannel gets called forever after despite
the fact that it is trying to turn itself off.
So...
1) Is the disabling of the draw traversal using setTravMode a "downstream
only" type of communication when multiprocessing?
2) Why does it work in when uniprocessing?
3) Do I even want to do it this way? If not, what is a better/cleaner way?
Thanks in advance,
scott
--
Scott McMillan / scott++at++ht.com / (301)984-3706 x250 / FAX (301)984-2104
High Techsplanations Inc.
6001 Montrose Road, Suite 902 / Rockville, MD 20852-4874
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:52 PDT