[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bgsdev::open3d

Title:open3d
Notice:Kits on notes 3 and 4; Documents note 223
Moderator:WRKSYS::COULTER
Created:Wed Dec 09 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1306
Total number of notes:5260

1229.0. "OpenGL/X synchronization problem on ZLXp-L and 4D40T" by PRSSOS::TISSERAND_P (Philippe TISSERAND, Digital Equipment France) Tue Jan 28 1997 15:10

Hi,

Some customers reported me abnormal behavior of applications based on OpenGL.

The so-called problem is related to object rotation started by mouse button
down, mouse motion and stopped when mouse button left up.

When you begin the mouse motion, the object rotation starts but when when you
stop the motion, the object goes on rotating for while.

It can be reproduced in the following configurations:

    1) AlphaStation 255 or 500
       ZLXp-L1, ZLXp-L2
       Digital UNIX V4.0A
       Open3D V4.0
       Pro/Engineer V17

    2) Customer application (using GLX) on

            AS500/333 128Mb
            PowerStorm 4D40T
            Digital UNIX V4.0A
            Open3D V4.1
       or
            AS500/500 256Mb
            ZLXp-L2
            Digital UNIX V4.0A
            Open3D V4.1

    3) I reproduced it with glutdino example on

       AlphaStation 200 4/166
       ZLXp-L2
       Digital UNIX V4.0A
       Open3D V4.2

    4) It seems the same behavior has been seen with Unigraphics but I don't
       have more nformation on the whole configuration at this time

At this time I did work on system tuning, since I was not sure it would improve
the execution in any way.

The glutdino example does not show any delay in the rotation when the window
has its initial size, but the problem occurs when the window is maximized.

It does not exhibit the same behavior when I replace the ZLXp-L2 with a ZLXp-E3.

Following a talk with Dick Coulter , here are my understanding of the problem:

    - this behavior is the expected one and is due to the boards design/driver
      implementation 

    - it's up to the application to deal with synchronization issues between 
      X events and OpenGL rendering
 
    - with ZLXp-E3, GLX treats only one stream for X events and OpenGL
      rendering, so that you do not have to be concerned with synchronization 
      issues

    - with ZLXp-L and 4D40T, GLX treats separate streams for X events and 
      OpenGL rendering, so that you have to write the synchronization code 
      yourself  

Feel free to correct any of these statements.

I'm wondering whether the following solutions are valid:

    - if you are working with GLX interface, you have to modify the X event
      loop in order to make some event compression on MotionNotify events
      so that you process these events only when there is no more job to do

    - why not using glXWaitGL() to do explicit synchronization ?

    - how is it possible to implement synchronization if you are working with
      the glut interface for which the event loop is managed by glutMainLoop()?

    - Beginning with Open3D V4.2, direct rendering is available with PowerStorm
      4D40T. Does this mean that the synchronization issue will not be so
      critical ?


Object rotation constrained by mouse motion being a basic feature of every CAD
application, I'm highly surprised that no CAD application user reported this 
behavior before the V4 releases of Digital UNIX and Open3D, since I believe a 
lot of customers are used to work with well-known CAD applications on Digital 
workstations with ZLXp-L boards ???

The problem here is not only related to an application developer error but
rather to CAD users reports of a platform abnormal behavior. 

In any case, if the behavior was reported only for customer internal
applications, it would be easy to debate about application design, but since
partners applications are involved, I think we have to investigate further on
this.

Thanks for any idea on how to solve this...

Philippe.
T.RTitleUserPersonal
Name
DateLines
1229.1The application must use glFInish to throttle the OpenGL queuesVESPER::VESPEROpenGL Alpha GeekTue Jan 28 1997 17:2988
>The so-called problem is related to object rotation started by mouse button
>down, mouse motion and stopped when mouse button left up.
>
>When you begin the mouse motion, the object rotation starts but when when you
>stop the motion, the object goes on rotating for while.

This is a classic problem dealing with OpenGL in the X11 windowing
system environment. The problem is that there are 3 queues --

	1. OpenGL rendering queue
	2. X11 rendering queue
	3. X11 input queue

and the application can put a lot of requests in the rendering queues.

Lets take the case where a frame takes 1 second to render, and the
mouse is moving and producing events every 1/10 second.

The application sees a mouse event at time t=0.0 and renders a frame.
Lets say it takes 5/10 second for the application to put 
frame 1 into the OpenGL rendering queue and call glXSwapBuffers (which
automatically flushes the 2 rendering queues.) It now looks at the
input queue and finds 5 new mouse events -- from t=0.1 to t=0.5. It compresses
the mouse events and renders frame 2 based on the mouse event at t = 0.5.
Frame 1 is only half done, so we have 1.5 seconds of rendering queued up.
After a few rounds of this, we can easily get tens of seconds of rendering
in the OpenGL rendering Queue.

The only solution to this is to throttle the application, and not let it
fill up the queues. We really can't do this effectively, which makes it up
to the application to throttle itself. It must do this by calling glFinish
every once in a while -- preferably every frame. This will stall the application
until time t=1 in our example above, so that there is never more than one
frame in the queue.

>The glutdino example does not show any delay in the rotation when the window
>has its initial size, but the problem occurs when the window is maximized.

The glut library as distributed by Digital should have a glFinish inside
the loop. From where did you get your glut library?

The size-dependent nature is because with a little window the frame
updates are fast enough to avoid the problem, but with a larger window
frames take longer to be rendered than the incoming mouse event stream allows.

>It does not exhibit the same behavior when I replace the ZLXp-L2 with a
>ZLXp-E3.

I don't understand why this would be the case.

>    - with ZLXp-E3, GLX treats only one stream for X events and OpenGL
>      rendering, so that you do not have to be concerned with synchronization 
>      issues
>
>    - with ZLXp-L and 4D40T, GLX treats separate streams for X events and 
>      OpenGL rendering, so that you have to write the synchronization code 
>      yourself  

The only difference with the -E3 is that the main CPU does more of the
work -- perhaps this is slowing down the application sufficiently.

>    - if you are working with GLX interface, you have to modify the X event
>      loop in order to make some event compression on MotionNotify events
>      so that you process these events only when there is no more job to do

This is required, but you also need to synchronize the input with the
rendering queue using glFinish.

>    - why not using glXWaitGL() to do explicit synchronization ?

glXWaitGL and glXWaitX only synchronize the two output queues, not the
event queue.

>    - how is it possible to implement synchronization if you are working with
>      the glut interface for which the event loop is managed by glutMainLoop()?

The glut library (__glutSetWindow) needs to be modified to put
the GLUT_FINISH_WORK item on the work list without regard to direct
or indirect rendering.

>    - Beginning with Open3D V4.2, direct rendering is available with PowerStorm
>      4D40T. Does this mean that the synchronization issue will not be so
>      critical ?

The direct rendering method used in the 4D40T series still requires the
application to self-throttle using glFinish.

Andy V
1229.2libglut.so provided with O3DDWSGLBASE420PRSSOS::TISSERAND_PPhilippe TISSERAND, Digital Equipment FranceWed Jan 29 1997 10:451
The glut library used is the one provided with O3DDWSGLBASE420 subset.
1229.3'use the source, Luke'VESPER::VESPEROpenGL Alpha GeekWed Jan 29 1997 11:477
>The glut library used is the one provided with O3DDWSGLBASE420 subset.

That should certainly have the fix. If you install O3DDWSGLEXAMP420,
you should get the sources for libglut and you can look to see what is
happening.

Andy V
1229.4WRKSYS::CHALTASIntelligence is no bad thingWed Jan 29 1997 12:424
    Meanwhile, we are working with Pro/Engineer to get a fix incorporated
    into their product(s).
    
    	George