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

Close

#31 First visiblity comes after first reshape.

open
nobody
nuisance (37)
1
2004-05-03
2003-12-11
Richard Rauch
No

This is a very low priority bug, since I am not sure
that it really affects anyone, the detail falls outside
of the GLUT spec., and it is possible that GLUT was not
consistant on this point anyway.

In GLUT on X11, the very first event sent to an
application is a visibility, I believe. On freeglut,
the fist event is a Reshape. Here
are corresponding initial outputs from a toy
application of mine:

/~~~ with GLUT

Main window visible: 1
Reshaped main window: 500, 500
Redisplay called.
Timer called (1)

\___ with GLUT

/~~~ with freeglut

Reshaped main window: 500, 500
Main window visible: 1
Redisplay called.
Timer called (1)

\___ with freeglut

(Timer events were set to be called every second.)

This won't matter much for most applications, but it is
conceivable that the sequence of callbacks will matter
in some cases, so if we can easily match GLUT, we should.

(Can someone confirm with WIN32 what happened with old
GLUT?)

Discussion

  • Richard Rauch
    Richard Rauch
    2003-12-11

    Source for the indicated event-generator program. (Links gainst either GLUT or freeglut.)

     
    Attachments
  • Richard Rauch
    Richard Rauch
    2003-12-11

    Logged In: YES
    user_id=854844

    I apparently forgot to "check" the box to indicate that the
    file I selected/indicated was in fact the file that I wanted
    to attach.

    The attached file is "main.cxx", a C++ program that can be
    built against either GLUT or freeglut, and which produces
    the output excerpted in the bug report.

     
  • Nigel Stewart
    Nigel Stewart
    2003-12-12

    Logged In: YES
    user_id=338692

    In my humble opinion it is more logical for the application
    to receive the visibility event _before_ the resize event.
    There doesn't seem much point in sending or handling
    resize events for invisible windows.

    Here is some diagnostic output for GLUT as distributed
    with Cygwin on Win32....

    --------------

    Cygwin with GLUT:

    nigels@zooropa /m/tmp/test$ g++ main.cxx -lglut32 -lglu32
    -lopengl32
    nigels@zooropa /m/tmp/test$ ./a.exe
    Main window visible: 1
    Main window entered: 1
    Glide motion in main window: 292, 223
    Reshaped main window: 500, 500
    Redisplay called.
    Timer called (1)
    Timer called (5)
    Timer called (25)
    Timer called (125)

    MingW32 with GLUT:

    nigels@zooropa /m/tmp/test$ g++ main.cxx -mno-cygwin
    -lglut32 -lglu32 -lopengl32
    nigels@zooropa /m/tmp/test$ ./a.exe
    Main window visible: 1
    Main window entered: 1
    Glide motion in main window: 223, 235
    Reshaped main window: 500, 500
    Redisplay called.
    Timer called (1)

     
  • Richard Rauch
    Richard Rauch
    2003-12-12

    Logged In: YES
    user_id=854844

    I agree that the GLUT behavior makes more sense. Does GLUT
    on CygWIN use X11? I'm nto familiar with MingW32 at all.

    Anyway, thanks for testing!

     
  • Nigel Stewart
    Nigel Stewart
    2003-12-12

    Logged In: YES
    user_id=338692

    Cygwin can either use win32 OpenGL or Mesa via X11..

    Cygwin to link with win32 GLUT, GLU and GL:

    g++ main.cxx -lglut32 -lglu32 -lopengl32

    To link with XFree GLUT, (Mesa) GLU and (Mesa) GL:

    g++ main.cxx -lglut -lGLU -lGL -L/usr/X11R6/lib

     
  • Logged In: YES
    user_id=335861

    As for freeglut:

    krzysiek:krzysiek# g++ main.cxx -o main -lfreeglut -lGL
    krzysiek:krzysiek# ./main
    Loading required GL library /usr/X11R6/lib/libGL.so.1.2
    disabling TCL support
    Main window visible: 1
    Redisplay called.
    Main window entered: 1
    Reshaped main window: 500, 500
    Redisplay called.
    Timer called (1)
    Timer called (5)

    First two lines come from drivers for my video card.
    Everything's ok on Linux MDK 9.2.

     
  • Nigel Stewart
    Nigel Stewart
    2003-12-29

    Logged In: YES
    user_id=338692

    Is it time to mark this as resolved?

     
  • Richard Rauch
    Richard Rauch
    2003-12-29

    Logged In: YES
    user_id=854844

    As far as I can see, nothing has changed. I resynced my
    copy of the current CVS and re-built my "events" test
    program. It still does the reshape before the first
    visibility. (I thought that nelchael_kp was just
    re-affirming my UNIX_X11 tests. Sorry for misreading. Mea
    culpa.)

    To nelchael_kp: Which freeglut did you use? Since GNU/LINUX
    and NetBSD both use the UNIX_X11 branch, behavior should be
    identical to what I observed on my NetBSD box. However, I
    was checking against the current CVS repository. It is
    possible that past releases did not exhibit
    this behavior.

     
  • Logged In: YES
    user_id=335861

    2.2.0

     
  • Richard Rauch
    Richard Rauch
    2003-12-31

    Logged In: YES
    user_id=854844

    I don't think that anything changed in this regard since
    then, but can you try current, anyway?

     
  • Richard Rauch
    Richard Rauch
    2004-02-01

    Logged In: YES
    user_id=854844

    Okay, I think that I see the problem. Duh. (^&

    CreateNotify: and ConfigureNotify: events are treated identically. This is sort-of necessary for sub-windows (since X won't generate an initial configure event; but GLUT sends reshape callbacks to *every* window upon creation, and it is easy for apps to rely upon that).

    The first event that you get for your window should be a CreateNotify: event, which should generate a reshape callback.

    We can work around this by storing the reported new size and setting a flag---then handling this during the fgDisplayAll() code. (WIN32 is already doing this, though I have some disagreements with some of the details of the WIN32 branch. We can reuse the same variables and get rid of the State.Old{Width,Height} variables, I think.)

    If there are no objections, I guess I'll put this on my plate.

     
  • Richard Rauch
    Richard Rauch
    2004-02-04

    • assigned_to: nobody --> rkrolib
     
  • Richard Rauch
    Richard Rauch
    2004-03-23

    Logged In: YES
    user_id=854844

    Last I tried, this was still a bug with freeglut.

    However, as I am no longer in a position to resolve it, can
    someone with access please reassign it, either to nobody
    or to themselves?

    Thanks.

     
  • Richard Rauch
    Richard Rauch
    2004-05-03

    • assigned_to: rkrolib --> nobody
     
  • Richard Rauch
    Richard Rauch
    2004-05-03

    Logged In: YES
    user_id=854844

    Is *any* freeglut developer actually reading this?

    I would find it ironic if the only people doing freeglut support are
    OpenGLUT developers. (Mostly Nigel and myself.)

    Yes, I could ask that it be unassigned, via one of the lists. But
    I've been using the lack of responsiveness on this subject to
    be a metric of freeglut's commitment to support.

    Well, I'll try reassigning it myself. Just for giggles. If that doesn't
    work, I'll let it sit a while longer.

     
  • Nigel Stewart
    Nigel Stewart
    2004-05-04

    Logged In: YES
    user_id=338692

    Richard,

    Is this fixed over in OpenGLUT land?

    Shall we just do some cut and paste and stop having
    our OpenGLUT chatter on the FreeGLUT bug reports? :-)

    Nigel

     
  • Richard Rauch
    Richard Rauch
    2004-05-04

    Logged In: YES
    user_id=854844

    No, it has never been fixed. Since we started OpenGLUT, I've
    spent a lot of time on administrivia and comparatively little
    time on bug-fixes like this issue. It was still a problem
    the last time that I checked.

    As for cutting and pasting, I can see rationales for both
    ways. Having, and closing, bug reports on OpenGLUT would
    be good. On the other hand, as we still have a lot of
    common issues with freeglut, it may be more helpful for
    users to see both projects' responses to bug reports in
    a single place.

    I guess if you want to copy-and-paste to OpenGLUT, I wouldn't
    mind. (^&

     
  • Richard Rauch
    Richard Rauch
    2004-08-17

    Logged In: YES
    user_id=854844

    Re. cutting and pasting:

    Since freeglut is not doing much with their bug database,
    and it woudl be helpful to have a list of bugs that OpenGLUT
    has resolved (and to be able to *close* them after we
    fix the issue), I am increasingly favoring the notion of
    pasting bug reports from freelut to OpenGLUT.

    I have put one in over on OpenGLUT, with a reference to
    the corresponding freeglut bug. I think that I have fixed
    the bug in OpenGLUT, but would like to see an OpenGLUT
    release with the fix, then direct the poster to try the
    current OpenGLUT release (0.6.3 or whatever it winds up
    being).