Bernard Leclerc (bernard.leclerc++at++discreet.com)
Wednesday, November 10, 1999 8:56 PM
void getorigin( long *x, long *y );
void getsize( long *x, long *y );
So I guess it's nothing new. Check it out...
http://reality.sgi.com/performer/perf-95-03/0228.html
----------------------------------------------------------------------------
Dan Mapes GSM: +31 621 264589
RoninWorks BV http://www.RoninWorks.com
Vechtensteinlaan 24
3601 CK Maarssen
Netherlands
----------------------------------------------------------------------------
-----Original Message-----
From: Bernard Leclerc <bernard.leclerc++at++discreet.com>
To: info-performer++at++sgi.com <info-performer++at++sgi.com>
Cc: Jean-Luc.Dery++at++discreet.com <Jean-Luc.Dery++at++discreet.com>
Date: Wednesday, November 10, 1999 8:56 PM
Subject: Round trip query to the X server.
>Platform: O2, IRIX 6.5.4f, performer_dev 2.2, performer_eoe 2.2.5
>
>We all know that doing a round trip request to the X server is a NO when
>real-time and stable update rates are required. Somehow, it seems to be
>the case here. I've been able to observe this behavior with simple.C
>
>Here is how. Use "par" to monitor the system activity while "simple" is
>running. The following command will monitor system calls to "read" and
>"select" for 3 seconds and write the results into file "simple.par".
>
> $ par -s -SS -n read -n select -o simple.par -u -t 3 simple x29.sv
>
>The file is fairly long but, near the end, you'll notice a steady state
>that resemble this:
>
>2159mS: read(7, <01 18 01 49 00>..., 32) = 32
>2161mS: read(7, 0x7fff28c0, 32) errno = 11 (Resource temporarily
>unavailable)
>2161mS: select(8, [7], 0, 0, 0)
>2162mS: END-select(8, [7], 0, 0, 0) = 1
>
>
>Notice the "Resource temporarily unavailable" message while reading from
>file descriptor 7. Also notice that the process will go to sleep because
>of the call to select().
>
>Now if we use dbx to find out where the program calls read(), the stack
>trace looks like this (I've simplified the output to increase
>readability):
>
>(dbx) t
>> 0 __select() [".../select.s":17, 0xfafc008]
> 1 _select() [".../selectSCI.c":30, 0xfb059f0]
> 2 _XRead() [".../XlibInt.c":492, 0xf71c29c]
> 3 _XReply() [".../XlibInt.c":1858, 0xf71e368]
> 4 XGetGeometry() [".../GetGeom.c":43, 0xf6f7890]
> 5 __glXGetDrawableSize() [".../glx_direct.c":358, 0xd993bd0]
> 6 FindWindowSize() [".../crm_context.c":260, 0xda51730]
> 7 ApplyViewport() [".../crm_context.c":274, 0xda51844]
> 8 __glim_Viewport() [".../so_xform.c":555, 0xdb39ce0]
> 9 pfChannel::pf_applyView() [".../pfChannel.C":4518, 0x5860e90]
> 10 ::pfFrame() [".../pfProcess.C":6283, 0x58a5278]
> 11 ::main() [".../simple.C":144, 0x10002cd4]
> 12 __start() [".../crt1text.s":177, 0x100025d8]
>(dbx) q
>
>
>This is strange. If you follow the trace from level 9, you see that
>Performer calls the Open GL library to re-apply the viewport. In turn,
>OpenGL calls X to obtain the window size. THAT'S causing the round trip
>request to the X server... and that breaks the stable update rate.
>
>Ok, you're gonna say that the O2 isn't capable of real-time performance.
>I know! But I still don't see why there's a need to get the window size
>when it hasn't changed.
>
>I also tried with
>
> pw->setWinType(PFPWIN_TYPE_X | PFPWIN_TYPE_NOXEVENTS);
> pw->setFullScreen();
>
>but that didn't helped.
>
>
>So the question remains: why is Performer/OpenGL doing a round trip
>request to the X server when no X event has been received to justify the
>query?
>
>
>Is this a bug in Performer? Or is it a problem with OpenGL on O2?
>
>
>Note that this behavior can't be seen on the Octane. It seems to be
>specific to the O2.
This archive was generated by hypermail 2.0b2 on Wed Nov 10 1999 - 15:59:37 PST