#25 glutMainLoopEvent() shoult return fgNextTimer()

open
nobody
Easy (28)
5
2004-04-29
2004-04-29
Leon Bottou
No

It would be very useful to have
glutMainLoopEvent() return fgNextTimer().
When integrating glut with other event loops
that provide timers, this would provide a means
to compute how long we can sleep before
invoking glutMainLoopEvent() again.

Another plus would be to have a X11 specific
glutGet(GLUT_CONNECTION_NUMBER)

This would considerable help the implementation
of OpenGL in Lush (lush.sourceforge.net).
It currently relies on walinking the internal
glut data structures...
<http://cvs.sourceforge.net/viewcvs.py/lush/lush/packages/opengl/glut.lsh>

Discussion

  • Leon Bottou

    Leon Bottou - 2004-04-29

    Logged In: YES
    user_id=42774

    In fact it would be better to return fgNextTimer()
    using glutGet(GLUT_TIME_TO_NEXT_TIMER) or something
    like this. The presence of the symbol GLUT_TIME_TO_NEXT_TIMER
    would be a good way to detect whether the feature is present.
    - L.

     
  • Richard Rauch

    Richard Rauch - 2004-05-03

    Logged In: YES
    user_id=854844

    I like the glutGet() notion, somewhat.

    We have talked about the general problem of the GLUT event
    loop and the way that it interferes with (e.g.) network
    programming.

    A problem with the timer is that you then are reduced to polling
    the GLUT API for window events. This is not too expensive,
    but is not exactly ideal. You also need to bear in mind joysticks
    (which are essentially timers, but not built with timers, in freeglut).

    You might be better off implementing your own timers if you are
    doing the equivalent of select() in your own code.

    Perhaps a refinement to your suggestion would be some kind of
    glutGet(GLUT_PENDING_EVENTS), to return 0 if there are none,
    and non-zero otherwise. Then implement a timer on your own,
    using a granularity according to the tolerences you feel are
    appropriate. Events would include "internal" events as well as
    window-system events (so timers, joystick-timers, and the effects
    of things such as glutPostRedisplay() would cause the glutGet()
    to return non-zero).

     
  • Leon Bottou

    Leon Bottou - 2004-05-03

    Logged In: YES
    user_id=42774

    I certainly need to do my own select in
    order to merge the various event sources.

    In Lush I can simultaneously use a freeglut window,
    a few native X window, a SDL window, an openinventor
    window (which calls glut internally), and a tablet input
    device. I want to be able to handle the events and timers
    related to all these "event sources". I do not have
    the option to change openinventor to use my timers
    instead of glut timers, or to change SDL code to use
    my timers instead of SDL timers

    Each event source can generate events resulting
    from device input (such as X11 events) or
    resulting from programmed timers.

    Each event source also comes with a function
    similar to glutMainLoopEvent() which processes
    events and returns when no events are
    pending anymore (including internal
    redisplay events, etc.).

    In order to build the arguments of my big select,
    I need to collect the file descriptors receiving
    device input events, and I need to know how
    much time there is before the first timer fires

    Therefore, for each event source,
    I need to know two things:
    - the connection number(s).
    - the time before the next timer event.

    This is why I was suggesting the following:
    glutGet(GLUT_CONNECTION)
    glutGet(GLUT_TIME_TO_NEXT_TIMER)

    This provides enough information to freely
    merge glut's event loop with other event loops.

    I only need glutGet(GLUT_PENDING_EVENTS)
    if glutMainLoopEvent() can return while events are still pending.
    If this is the case, I would do
    { while (glutGet(GLUT_PENDING_EVENTS))
    glutMainLoopEvent(); }

     
  • Richard Rauch

    Richard Rauch - 2004-05-03

    Logged In: YES
    user_id=854844

    The file descriptor number may be a hard thing to get freeglut to
    give you. Strictly portable interfaces are a big thing in the freeglut
    goal list. An X connection file descriptor doesn't fit so well into a
    WIN32 application. (^& I believe that there is a way to obtain
    a list of open file descriptors for your process in UNIX. Could
    you use that to determine which descriptors you need to select()
    on?

    As for the timer, I think that I now understand your point.

    However, the freeglut internal function you want to call is only
    useful for proper GLUT timers, and so it would not actually be
    general enough. (But that could be addressed by someone doing
    the requisite cleanup to the freeglut timed event code. I had
    meant to do that while I was still working on freeglut, but it never
    got to the front of my queue.)

    The idea seems sound, though, if that infrastructure were updated
    in the necessary way. (^&

     
  • Leon Bottou

    Leon Bottou - 2004-05-04

    Logged In: YES
    user_id=42774

    > An X connection file descriptor doesn't fit so
    > well into a WIN32 application.
    Under WIN32 you do not need it because it is
    implicit in MsgWaitForMultipleObjects(...).
    This is why I was proposing to return -1
    when this is not applicable.

    Anyway, I will help myself and propose
    a patch based on the latest CVS
    with comments explaining the API
    as precisely as possible.

    - L.

     
  • Richard Rauch

    Richard Rauch - 2004-05-04

    Logged In: YES
    user_id=854844

    What do you do on an Amiga, where you need the MsgPort? Or
    on <insert OS of choosing>?

    freeglut has already ruled out some other useful things
    precisely because the feature was not known to be portable.
    (E.g., restricting the mouse pointer to the current window
    was one, I believe. Easily done on X, and someone was
    offering to do the legwork for WIN32; the project owner
    refused to allow it on the grounds that there might exist
    a system where it would not work.)

    Feel free to post a proposal, though. There's always a
    chance he'll be in a mood to consider it. (^&

     
  • Leon Bottou

    Leon Bottou - 2004-05-04

    Logged In: YES
    user_id=42774

    > What do you do on an Amiga, where you need the MsgPort?
    On the Amiga you need a signal mask for function Wait.
    This can be returned by glutGet(GLUT_CONNECTION) as well.

    Anyway, the attached patch contains the following things:

    glutGet(GLUT_CONNECTION) ---
    Returns a system dependent integer indicating
    how to wait for window system events pertaining
    to the windows managed by freeglut.
    - Unix: this is a file descriptor for function select()
    - Win32: always return -1

    glutGet(GLUT_IDLE_TIME) ---
    Returns the expected idle time.
    The main loop should not wait more
    than the expected idle time (in milliseconds)
    before calling glutMainLoopEvent() again.

    Remark1: The main loop must still call glutMainLoopEvent()
    as soon as there are pending window system events.
    But it should also call glutMainLoopEvent() within
    the specified idle time regardless of the presence
    of pending window system events. This is used for
    timers, joysticks, etc...

    Remark2: A return value of 0 indicates that
    glutMainLoopEvent() has something do

    It also includes a fix for bug #944577.

     
  • Leon Bottou

    Leon Bottou - 2004-05-14
     
  • Richard Rauch

    Richard Rauch - 2004-08-29

    Logged In: YES
    user_id=854844

    Regarding this and your freeglut Bug report, I have filed
    parallel OpenGLUT Bug and RFE reports:

    OpenGLUT Bug #1016512.
    OpenGLUT RFE #1018263.

    I have filed some further comments on the patch in the RFE.
    I *think* that the Bug is fixed and can be marked Closed, but
    would like some verification if you can spare the time to
    check.

    Thanks.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks