Moshe Nissim (moshe++at++orad.co.il)
Tue, 06 Oct 1998 15:58:23 +0300
> I encountered the same problem a while ago.
Yes, I've seen your post back then.
The problem you reported is similar, yet different, because:
1. Yours happens only with 2.2. What I found happens in 2.1 too.
2. I think yours happens only when multi-processing
3. Yours is caused by pfPipeWindow::pf_updateWindow(). "Mine" is caused
indirectly by glViewport() which is called from pfChannel::pf_applyView()
This led me to beleive that the problem is differet.
> Conclusions:
>
> When the APP stage process is locked on a CPU, internal handling of the
> pfPipeWindow for managing the window starts behaving badly. The sticky resizing
> problem is most certainly something that as to do with the DRAW process.
>
> The goog thing about this is that the problem is solved in the latest Performer
> patch 3229:
>
> o SCR 611816 - pfPipeWindow resize with forked cull caused slow &
> per-frame X communication
>
> We've upgraded to the patch and it does solve the problem.
>
> I just hope you are experiencing the same problem; else, well, forget this.
>
Why don't you check if "my" problem occurs with 2.2+3229?
One way to do this: dbx perfly, setenv DISPLAY "unix:0", run,
(my favorite args: -P 0 -E clear -W 16,16 -r 75 -g 0 -m 0)
wait for it to "settle down", stop in write, continue.
If it stops, then there's X11 communication going on. Look at the stack
trace and you'll see pfChannel::pf_applyView is calling glViewport().
Another way: run xscope -i1 -o0 -q, setenv DISPLAY :1, run perfly, and see if
the xscope trace ever gets quiet.
I'll check it too when I get patch 3229
Bye,
Moshe
-- Moshe Nissim, Orad Hi-Tec Systems Tel: (972) - 9 - 7676862 (ext. 579) Fax: (972) - 9 - 7676861 Email: moshe++at++orad.co.il
This archive was generated by hypermail 2.0b2 on Tue Oct 06 1998 - 06:58:42 PDT