Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#6 Callbacks fire earlier than they do in GLUT.

closed
nobody
critical (31)
7
2003-12-12
2003-07-30
No

Freeglut has a problem with callbacks, Steve
Baker's PUI, and an inocculous PUI example program
named "complex.cpp" ( find it here:
http://plib.sourceforge.net/dist/plib_examples-
1.6.1.tar.gz ).

This program simply crashes with an access
violation when built with Freeglut on Win2k with MSVC 6.
The program ran fine on GLUT last I checked. Here's the
problem:

The file has an utterly normal GLUT initialization
with PUI, which (abbreviated) looks like this:

int main ( int argc, char **argv )
{
firsttime = TRUE;

glutInitWindowPosition( 100, 0 ) ;
glutInitWindowSize ( 640, 480 ) ;
glutInit ( &argc, argv ) ;
glutInitDisplayMode ( GLUT_RGB | GLUT_DOUBLE |
GLUT_DEPTH ) ;
main_window = glutCreateWindow ( "Complex PUI
Application" ) ;
glutDisplayFunc ( displayfn ) ;
glutKeyboardFunc ( keyfn ) ;
glutSpecialFunc ( specialfn ) ;
glutMouseFunc ( mousefn ) ;
glutMotionFunc ( motionfn ) ;

#ifdef VOODOO
glutPassiveMotionFunc ( motionfn ) ;
#endif

glutIdleFunc ( displayfn ) ;

puInit () ;

#ifdef VOODOO
puShowCursor () ;
#endif

{...}

save_window = glutCreateWindow ( "Saving" ) ;
glutDisplayFunc ( savedisplayfn ) ;
glutKeyboardFunc ( keyfn ) ;
glutSpecialFunc ( specialfn ) ;
glutMouseFunc ( mousefn ) ;
glutMotionFunc ( motionfn ) ;
glutPassiveMotionFunc ( motionfn ) ;
glutIdleFunc ( savedisplayfn ) ;
glutReshapeFunc ( savereshapefn ) ;
glutHideWindow () ;

{...}

glutMainLoop () ;
return 0 ;
}

The window in question is save_window.
save_window has two unique callbacks, savedisplayfn()
and savereshapefn(). save_window is glutCreate'd in the
main loop but is not initialized (had its GUI widgets built)
until a menu item is clicked, executing the save_cb()
function, which looks like this:

static void save_cb ( puObject * )
{
static int save_count = 0 ; // Number of buttons in file
picker
int w = 320, h = 270 ;
glutSetWindow ( save_window ) ;
glutShowWindow () ;
glutReshapeWindow ( w, h ) ;
glutPositionWindow ( ( 640 - w ) / 2, ( 480 - h ) / 2 ) ;
if ( ++save_count > 2 ) save_count = 0 ;

file_selector = new puFileSelector ( 0, 0, w, h,
save_count, ".", "Pick Place To Save" ) ;
file_selector -> setCallback ( pick_cb ) ;
file_selector->setChildStyle ( PUCLASS_ONESHOT,
PUSTYLE_BOXED ) ;
file_selector->setChildBorderThickness (
PUCLASS_ONESHOT, 5 ) ;
file_selector->setChildColour ( PUCLASS_SLIDER, 0,
0.5, 0.5, 0.5 ) ;
}

At that point, file_selector becomes initialized
with a new puFileSelector widget object. Before that,
file_selector is NULL. Unfortunately, the savereshapefn()
tries to resize file_selector as follows:

static void savereshapefn ( int w, int h )
{
file_selector->setSize ( w, h ) ;
}

Herein lies the problem. In GLUT this callback
to resize the window apparently is not called until after
the window has been created. Freeglut calls this
callback almost immediately, before the window has
been setup and file_selector set to a real object. Even
save_cb() itself calls glutReshapeWindow() (and hence
savereshapefn()) before actually giving file_selector a
value. GLUT must not execute callback functions until a
window has been fully created, but how does it know?
Obviously a nullcheck in savereshapefn() would fix this,
but this doesn't change the fact that we're breaking a
former GLUT program.

Discussion

  • PUI's example file mentioned above.

     
    Attachments
  • John F. Fay
    John F. Fay
    2003-08-01

    Logged In: YES
    user_id=70811

    I fixed this partway so that the reshape function doesn't get
    called until the window is made visible. Unfortunately this is
    only a partial solution because the sample program makes the
    window visible and reshapes it before defining the
    widget. "freeglut" calls the reshape callback immediately
    while GLUT waits until the next round of displays before
    calling the reshape callback.

     
  • Nigel Stewart
    Nigel Stewart
    2003-10-01

    Logged In: YES
    user_id=338692

    I am observing a problem with 2.0.0 in Linux, but not
    in Windows:

    My application is receiving a display callback very soon
    after the window is created. However, my application
    is expecting a resize event before this. It is common
    to setup the modelview matrix in the resize handler,
    as well as other once-in-a-while initialisation. Also, it would
    be good for FreeGLUT to handle pending timers before
    calling the display function. I am not observing this
    problem on Windows with 2.0.0.

    I think a diagnostic application that simply logs all
    application callbacks would be helpful in diagnosing
    problems and comparing with FreeGLUT. I am noticing
    other strangeness such as many visibility events,
    that also ought to be resolved.

     
  • Richard Rauch
    Richard Rauch
    2003-11-07

    Logged In: YES
    user_id=854844

    Under NetBSD, I saw the same thing that Nigel reports below.
    It was causing severe problems in any program that didn't
    want (effectively) a default reshape event called on the
    window for the first reshape (the one when the window is
    opened) for SUBwindows.

    I think that I fixed it (at least on UNIX_X11---i.e.,
    NetBSD). You might check if your LINUX system is working
    better for you, now.

    Without this, you had to (if using freeglut) insert a hack
    into your program to reshape its own window once,
    "manually", to get window shape info for your initial window
    configuration.

     
  • Richard Rauch
    Richard Rauch
    2003-11-07

    Logged In: YES
    user_id=854844

    Under NetBSD, I saw the same thing that Nigel reports below.
    It was causing severe problems in any program that didn't
    want (effectively) a default reshape event called on the
    window for the first reshape (the one when the window is
    opened) for SUBwindows.

    I think that I fixed it (at least on UNIX_X11---i.e.,
    NetBSD). You might check if your LINUX system is working
    better for you, now.

    Without this, you had to (if using freeglut) insert a hack
    into your program to reshape its own window once,
    "manually", to get window shape info for your initial window
    configuration.

     
  • Richard Rauch
    Richard Rauch
    2003-11-07

    Logged In: YES
    user_id=854844

    Under NetBSD, I saw the same thing that Nigel reports below.
    It was causing severe problems in any program that didn't
    want (effectively) a default reshape event called on the
    window for the first reshape (the one when the window is
    opened) for SUBwindows.

    I think that I fixed it (at least on UNIX_X11---i.e.,
    NetBSD). You might check if your LINUX system is working
    better for you, now.

    Without this, you had to (if using freeglut) insert a hack
    into your program to reshape its own window once,
    "manually", to get window shape info for your initial window
    configuration.

     
  • Richard Rauch
    Richard Rauch
    2003-11-07

    Logged In: YES
    user_id=854844

    Under NetBSD, I saw the same thing that Nigel reports below.
    It was causing severe problems in any program that didn't
    want (effectively) a default reshape event called on the
    window for the first reshape (the one when the window is
    opened) for SUBwindows.

    I think that I fixed it (at least on UNIX_X11---i.e.,
    NetBSD). You might check if your LINUX system is working
    better for you, now.

    Without this, you had to (if using freeglut) insert a hack
    into your program to reshape its own window once,
    "manually", to get window shape info for your initial window
    configuration.

     
  • Richard Rauch
    Richard Rauch
    2003-11-14

    Logged In: YES
    user_id=854844

    What is the status of this bug?

    If it is still a problem, can a simple example (MINIMAL; no
    dragging in other libraries or extraneous(?) things like
    software-mouse-cursor) be posted for analysis? I'd like to
    close out some more bugs, but do not know PUI.

     
  • Nigel Stewart
    Nigel Stewart
    2003-12-12

    Logged In: YES
    user_id=338692

    Is this resolved in 2.2.0 RC2?

     
  • Richard Rauch
    Richard Rauch
    2003-12-12

    Logged In: YES
    user_id=854844

    There are still issues about the reshape handling.

    On X11, reshape callbacks happen when a ConfigureNotify or
    CreateNotify(?) event occurs.

    On WIN32, callbacks happen when freeglut has been asked
    (either by WIN32 or by the application) to do the resize.
    (WIN32 does the callback and and the resize together---in
    fgReshapeWindowByHandle().)

    On both systems, freeglut asks the window system to resize
    the window (AdjustWindowRect() on WIN32, and XResizeWindow()
    on X11) inside fghReshapeWindowByHandle().

    This leads to the identical code for the callback invocation
    occuring in two separate places. This should not be, but
    will suffice for the release I think.

    Another problem is that the *request* from the application
    to resize the window (and from WIN32 on WIN32 systems) is
    only honored if the window has a pending redisplay and is
    visible. This, IMHO, is wrong---resizing the window may
    change the window's visibility and (when the resize is
    eventually performed) may result in a client reshape
    callback that in turn does a glutPostRedisplay().

    So: There are still problems with the reshape handling, and
    they may be thorny to sort out since WIN32 and X11 seem to
    take fundamentally different approaches to who really
    controls the window (the window system or the application).

    I'm not sure if it is better to close this one out if the
    immediate problem is solved, or leave it open as a
    discussion thread/history of related issues.

     
  • John F. Fay
    John F. Fay
    2003-12-12

    • status: open --> closed
     
  • John F. Fay
    John F. Fay
    2003-12-12

    Logged In: YES
    user_id=70811

    Yes, this has been fixed.