From: William Sherman -Visualization (wsherman++at++ncsa.uiuc.edu)
Date: 06/21/2002 12:33:59
Hello,
I'm not sure if reporting pfBugs is part of the lists' etiquette, but
I guess other pf'ers might be interested to know about them -- though
I'm sure these are seldom used functions.
I'm testing my system on three/four platforms. Some of the bugs
appear on all platforms, others not. The platforms I'm testing
on are Performer 2.2 on an Onyx2 and an O2, Performer 2.3 on
Linux and Performer 2.5 on Linux.
The first set of bugs concern pfRemoveChan(), pfAddChan() and pfNewChan(),
and behave the same in all the platforms tested. These operations
are all performed on a configuration with a single pfPipe, with
multiple pfPipeWindows on that pipe, and one pfChannel for each
pfPipeWindow.
The pfRemoveChan() function may remove a channel from a pipewindow that
was not specifed as the argument. If the given channel goes to the
specified pipewindow, then pfRemoveChan() seems to work fine. However,
if the channel isn't tied to the given pipewindow, then that channel
will be removed from some other pipewindow, which is clearly a bug.
I probably wouldn't have discovered the above bug if pfAddChan() hadn't
behaved in a way counter to what is suggested in the man page. Specifically,
when adding a channel to a different pipewindow, the channel is also
removed from the pipewindow it had been attached to. It makes sense
that a channel can only belong to one pipewindow, so this is okay, but
the man page should probably state this.
And I wouldn't have noticed either of the above if pfNewChan() had a
little more sensible behavior. Namely, it would make more sense if
pfNewChan() added the newly created channel to the most recently
created pipewindow of the given pfPipe, rather than always adding
it to the first pipewindow. If I've recently created a new pipewindow,
then it's very likely that any new channels I create are for that
pipewindow, not an older pipewindow for which I've probably already
created all the channels.
However, I can basically get what I want by creating the channel,
and then moving it to the correct pipewindow with pfAddChan() -- and
NOT calling pfRemoveChan(). Once I have my channels going to the
correct pipewindows, things seem to work, with one exception -- 2D
text only appears on the first pipewindow of the pfPipe (ie. the
text of the pfStats). I'm also seeing some odd behavior with
keyboard inputs going to the wrong pipewindow, but I haven't had
time to determine if that's my fault yet.
And on another topic, pfMultipipe() works on some of the platforms
I'm testing, but not on all. Specifically, it seems to work fine
on IRIX Performer (2.2 at least), and also on version 2.3 on Linux.
It does not work on version 2.5 on Linux. Because the Linux versions
only allow one pfPipe, those are the platforms I am most concerned
with, and the fact that it worked on an older version of Performer,
but not the newer version is a concern.
On version 2.3/Linux, pfMultipipe() will return an error code when
more than one pipe is requested, and pfGetMultipipe() will always
return the value of '1'. Perfect. Unfortunately, on 2.5/Linux
pfMultipipe() will accept values of greater than one, and
pfGetMultipipe() will report however many pipes were requested. The
problem comes when trying to use more than one pipe -- core dump.
It would be beneficial if pfMultipipe() and pfGetMultipipe() on
future version of Linux Performer would allow only 1 pipe to be
created -- unless of course Performer will work with multiple pipes.
Fortunately, I've found work arounds for my problems, so my system
is working fine now. But I thought my week of debugging may be
beneficial to others on the list, and perhaps will improve future
versions of Performer.
Bill
-- Bill Sherman VR Impresario NCSA Virtual Environments Group wsherman++at++ncsa.uiuc.edu
This archive was generated by hypermail 2b29 : Fri Jun 21 2002 - 12:34:27 PDT